MCP-Endpoint

Tale ist selbst ein MCP-Server. Richte einen beliebigen MCP-Client — ein Agent-Harness, eine IDE, deine eigene SDK-Schleife — auf einen Endpoint, und er kann Automatisierungen autorieren und betreiben, durchsuchen, was die Organisation kann, eine Capability aufrufen und Wissen abrufen — mit demselben API-Schlüssel wie die REST-Oberfläche. Wo REST die Connectorsnaht für deinen Code ist, ist der MCP-Endpoint die Naht für Modelle: jedes Tool antwortet Text, den ein Modell lesen und verwerten kann.

Lies das, um einen Client zu verbinden und das Tool-Inventar zu verstehen. Die Grammatik zum Autorieren von Automatisierungen ist hier bewusst nicht dupliziert — der Endpoint lehrt sie selbst, über get_docs.

Einen Client verbinden

Der Endpoint spricht MCP-Protokoll 2025-03-26 als JSON-RPC über HTTPS — reine JSON-Antworten, kein SSE-Stream, eine Nachricht pro Request (ein Batch antwortet Fehler -32600). Authentifiziere mit einem Organisations-API-Schlüssel (API-Schlüssel beschreibt das Erzeugen):

// POST https://your-host.example.com/api/v1/mcp
// Authorization: Bearer tale_...
{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {} }

Der Server identifiziert sich als tale-platform. In einem Client mit Config-Block ist das alles, was du brauchst:

{
  "mcpServers": {
    "tale": {
      "url": "https://your-host.example.com/api/v1/mcp",
      "headers": { "Authorization": "Bearer tale_..." }
    }
  }
}

tools/list liefert das volle Inventar; GET auf den Endpoint antwortet 405 — es gibt keinen Event-Stream zum Abonnieren. Die Endpoint-URL deines Deployments, dasselbe Inventar in seinen drei Gruppen und eine kopierbare tools/list-Anfrage findest du unter Einstellungen > API > MCP.

Die Tools

Zweiundzwanzig Tools, in drei Gruppen. Die Autoring-Tools nehmen ganze Automatisierungsdokumente und validieren alles selbst — ihre Schemas sind auf dem Draht offen, und get_docs ist die Referenz, die ein Modell zuerst liest. Die Verwaltungs- und Capability-Tools nehmen einfache Argumente und deklarieren echte JSON-Schemas.

Autorieren

Lauf- & Trigger-Verwaltung

Nimm run_deployed, wenn die Automatisierung schnell ist und du einen Aufruf mit der Antwort darin willst — es wartet bis zu 30 Sekunden auf den Lauf und gibt dir danach die runId statt eines halbfertigen Ergebnisses. Nimm start_run, wenn der Lauf Minuten dauern darf — er gibt sofort eine runId zurück, und get_run pollt sie. Beide laufen live auf demselben dauerhaften Runner, autorisieren, führen aus und protokollieren den Lauf also identisch. run_automation ist das Tool der Authoring-Schleife: Es führt ein ungespeichertes Dokument gegen die deterministischen Mocks aus, und mode: "live" antwortet mit einer Ablehnung, die auf run_deployed zeigt — ein ungespeichertes Dokument hat keinen Live-Pfad.

start_run nimmt außerdem eine optionale projectId — das Projekt, in dem der Lauf arbeitet, sodass seine Aufgaben- und Dokument-Tools dort wirken. Lass sie weg für einen organisationsweiten Lauf oder, wenn die Automatisierung an ein einzelnes Projekt gebunden ist, für dieses. Eine gebundene Automatisierung akzeptiert nur ein Projekt, an das sie gebunden ist.

Capabilities & Wissen

In dieser Version hält die Registry die deployten Automatisierungen der Organisation — invoke_capability auf einer davon ist derselbe Akt wie run_deployed. Builtin-Tools, Connector-Aktionen, Skills und externe MCP-Server gehören nicht zu dieser Registry; eine id, die keine deployte Automatisierung ist, bekommt eine lesbare Ablehnung, keinen Fehler. Eine Capability, die die Organisation hinter eine Freigabe stellt, läuft nicht lautlos — invoke_capability antwortet mit einem Pending-Approval-Ergebnis, das das Modell weitergeben kann.

Was der Schlüssel darf

Der Schlüssel beweist, wer anruft; die Rolle seines Besitzers entscheidet, was der Aufruf darf — genau wie im Produkt:

• Jeder Mitglieds-Schlüssel — jedes Lese-Tool, run_automation (immer gegen die Mocks), search_capabilities, get_knowledge.
• Entwickler-Fähigkeit nötig — save_automation, deploy_automation, set_trigger, delete_trigger, cancel_run und Live-Ausführung (run_deployed, start_run).

Ein abgelehnter Aufruf ist kein Protokollfehler: das Tool antwortet mit einer lesbaren Ablehnung — {"error": "...", "hint": "..."} — damit das aufrufende Modell sich anpassen kann, statt abzustürzen. Diese Konvention gilt überall: Validierungsprobleme, fehlende Deployments und Rollenablehnungen kommen als Daten zurück; isError ist für Aufrufe reserviert, die wirklich geworfen haben.

Wo das hingehört

Der MCP-Endpoint und die REST-API sind eine Oberfläche in zwei Dialekten — derselbe Schlüssel, dieselbe Organisations-Scopung, dieselben Lauf-Objekte (start_run hier und POST .../runs dort erzeugen denselben durablen Lauf). Eigene MCP-Server bindet Tale in dieser Version nicht an — der Endpoint ist seine einzige MCP-Oberfläche, und die Richtung ist immer nach innen: Dein Client steuert Tale.