betool von Claude aus steuern (MCP)

Claude, Claude Desktop oder jede MCP-App per API-Schlüssel oder OAuth 2.1 mit betool verbinden: Konfiguration lesen, Änderungen zur Freigabe vorschlagen.

betool stellt einen MCP-Server (Model Context Protocol) bereit: Ein externer MCP-Client — Claude Code, Claude Desktop oder jede kompatible Anwendung — kann die Konfiguration Ihrer Organisation lesen und Änderungen in natürlicher Sprache vorschlagen (eine Pipeline, eine Rolle, eine Mission, eine Evaluation erstellen/bearbeiten…). Es ist wie ein Assistent, der betool mit Ihnen konfiguriert, vollständig governt.

Zwei Wege der Verbindung, zum selben Endpunkt https://platform.betool.ai/mcp:

ein MCP-API-Schlüssel im Header Authorization — am einfachsten für Claude Code;
OAuth 2.1 + PKCE — für Anwendungen Dritter, ohne Umgang mit einem Geheimnis.

Nichts wird ohne ausdrückliche Zustimmung angewendet. Jede Änderung läuft über einen Vorschlag. Mit dem Geltungsbereich Lesen + Vorschläge genehmigen Sie ihn mit einer Schaltfläche Akzeptieren und anwenden innerhalb von betool. Mit dem Geltungsbereich Voll darf die Anwendung ihre eigenen Vorschläge auflösen — nachdem Sie in deren eigener Unterhaltung zugestimmt haben; das ist das maschinelle Äquivalent dieser Schaltfläche, diesem Geltungsbereich vorbehalten und wie alles andere auditiert. Wählen Sie Lesen + Vorschläge, wenn die Bestätigung in betool erfolgen soll und nirgendwo sonst.

Was Claude tun kann

Lesen: Modellinventar, Graph und Knoten einer Pipeline, Konfigurationsverträge von Knoten, Rollen/Missionen, verfügbare Tools, Wissensbasis.
Ihre Daten lesen: die No-Code-Datenbanken Ihrer Organisation — Datenbanken, Tabellen, Spalten und Zeilen. Der Client entdeckt sie selbst; ein Schlüssel lässt sich nicht auf eine Teilmenge der Datenbanken beschränken.
Vorschlagen: über das Tool proposals.create einen ausstehenden Änderungsvorschlag — den Sie in der Oberfläche akzeptieren oder ablehnen. Das umfasst auch die Erstellung eines Modells und den Start eines Benchmarks (siehe Was vorgeschlagen werden kann).
Daten schreiben (Geltungsbereich Voll): eine Zeile in einer Ihrer Datenbanken anlegen, aktualisieren oder beanspruchen — nach Ihrer ausdrücklichen Zustimmung in der Unterhaltung. Anders als die Konfiguration ist ein Datenschreibvorgang nicht versioniert — er lässt sich nicht wiederherstellen.
Mit Ihren Modellen sprechen (Geltungsbereich Voll): eine mehrstufige Unterhaltung mit einem Modell führen, das Sie ausdrücklich für externe Agenten geöffnet haben — siehe unten.

Claude ermittelt den genauen Vertrag jedes Knotens (Felder, zulässige Werte), bevor es einen Vorschlag macht: kein Raten, keine ungültige Konfiguration.

Die Secrets einer Konfiguration (HMAC-Secret, Token, Passwort) erreichen es nie: models.inspect_pipeline und die Vorschläge geben sie maskiert zurück. Ein Vorschlag, der eine Konfiguration so zurücksendet, wie er sie gelesen hat, behält das gespeicherte Secret, ohne dass die KI es gesehen hat.

Die bereitgestellten Tools

Die Tools sind nach Familien gruppiert. Der Client entdeckt sie beim Verbinden selbst; die Tools eines Konnektors erscheinen nur, wenn Ihre Organisation ihn nutzt.

Familie	Tools	Rolle
`models`	`list_models`, `lookup_model`, `list_groups`, `inspect_pipeline`, `list_contexts`, `get_pipeline_trace`, `get_exchange_metadata`, `automation_health`, `get_entry_endpoints`	Modellinventar, Lesen einer Pipeline und ihrer Ausführungen, Zustand blockierter Automatisierungen
`pipeline`	`list_node_kinds`, `lookup_node_contract`, `lookup_module`, `list_all_tools`, `list_config_options`, `list_schemas`, `validate`	Knotenverträge, Konfigurationsoptionen, Validierung eines Graphen vor dem Vorschlag
`agents`	`list_roles`, `lookup_role`, `list_missions`, `lookup_mission`	Rollen und Missionen Ihrer Agenten
`benchmarks`	`list`, `get`, `list_check_kinds`, `list_runs`, `get_run`, `run_status`	Evaluationsszenarien und Ergebnisse ihrer Runs
`knowledge`	`search`	Suche in Ihrer Wissensdatenbank
`database_query` / `database_manage`	Lesen; `create_row`, `update_row`, `claim_row`	Ihre No-Code-Datenbanken (Schreiben: Geltungsbereich Voll)
`conversation`	`open`, `send`, `poll`, `history`	Mit einem Modell sprechen (siehe unten)
`proposals`	`create`, `describe_kind`, `apply`, `reject`	Eine Änderung vorschlagen, ihren Vertrag lesen, sie auflösen (`apply` / `reject`: Geltungsbereich Voll)

Die Eingangs-URL eines Modells, bereit zum Einfügen. models.get_entry_endpoints liefert die vollständige öffentliche URL jedes am Start eines Modells deklarierten Empfängers (eingehender Webhook, Callback einer Messaging-Plattform…) — so können Sie sie an einen Partner weitergeben, ohne den Pfad in der Oberfläche zu suchen.

Was vorgeschlagen werden kann

Jede Konfigurationsänderung läuft über proposals.create(kind, payload). Bevor er eine Nutzlast schreibt, liest der Client ihren genauen Vertrag mit proposals.describe_kind(kind). Die verfügbaren Kinds:

Kind	Wirkung nach Annahme
`model_create`	Erstellt ein Modell (Prozess) — seine Bezeichnung, seine Beschreibung, seine Gruppe
`model_update`	Ändert die Metadaten eines bestehenden Modells
`pipeline_edit`	Bearbeitet den Graphen eines Modells (Hinzufügen, Ändern, Löschen von Knoten und Verbindungen)
`pipeline_publish`	Veröffentlicht den aktuellen Stand eines Modells, nach der Validierung vor der Veröffentlichung
`pipeline_plan`	Verkettet Bearbeitungen und dann eine Veröffentlichung am selben Modell, mit einer einzigen Annahme, atomar
`role_update` / `mission_update`	Erstellt oder ändert eine Rolle / eine Mission eines Agenten
`knowledge_update`	Erstellt oder aktualisiert einen Texteintrag der Wissensdatenbank
`knowledge_document_replace`	Ersetzt die Datei eines Dokuments der Wissensdatenbank, an Ort und Stelle: gleiche Kennung, gleicher öffentlicher Link
`database_schema_edit`	Ändert die Struktur einer No-Code-Datenbank (Datenbanken, Spalten)
`benchmark_create` / `benchmark_update` / `benchmark_delete`	Verwaltet die Evaluationsszenarien
`benchmark_run`	Startet einen Benchmark-Run — als Vorschlag, weil ein Run Credits verbraucht
`credit_topup`	Manuelle Gutschrift auf ein Guthaben — der Betreiberorganisation der Plattform vorbehalten und von der begünstigten Organisation validiert

Einen Prozess von Anfang bis Ende erstellen = mehrere Zustimmungen. model_create erstellt die Instanz; ein pipeline_edit verdrahtet anschließend ihren Start (mit seinen Empfängern) und ihre Knoten; ein pipeline_publish nimmt sie in Betrieb. Eine Instanz zu erstellen und sie zu verdrahten bleiben zwei getrennte menschliche Entscheidungen.

Einen MCP-Schlüssel erstellen

Nur für Administratoren der Organisation: Ein Schlüssel trägt Autorität über die gesamte Organisation.

Öffnen Sie in betool Organisationseinstellungen → MCP.
Benennen Sie den Schlüssel und wählen Sie seinen Geltungsbereich:
- Nur lesen — liest die Konfiguration und die Daten in Ihren Datenbanken, liest die über diesen Kanal geöffneten Unterhaltungen erneut, schlägt nichts vor;
- Lesen + Vorschläge (empfohlen) — liest und reicht Vorschläge ein, die Sie in betool genehmigen;
- Voll — darf zusätzlich eigene Vorschläge auflösen, in Ihre Datenbanken schreiben und mit Ihren Modellen sprechen, nach Ihrer Zustimmung in der Unterhaltung des Clients.
Der rohe Schlüssel wird nur einmal angezeigt — kopieren Sie ihn sofort (er kann niemals erneut gelesen werden). Sie können einen Schlüssel jederzeit widerrufen.

Dieselben drei Geltungsbereiche gelten für OAuth; dort wählen Sie sie auf dem Zustimmungsbildschirm.

Claude Code verbinden

Fügen Sie den betool-MCP-Server zu Claude Code hinzu (der Schlüssel gehört in den Header Authorization):

claude mcp add betool \
  --transport http \
  --header "Authorization: Bearer <your-mcp-key>" \
  https://platform.betool.ai/mcp

Bitten Sie Claude dann in natürlicher Sprache: „inspiziere meine Pipeline X und schlage einen Schritt vor, der das Ticket zusammenfasst, bevor es gesendet wird“. Claude liest die Konfiguration, verfasst einen Vorschlag, und Sie validieren ihn in betool.

Fügen Sie niemals Geheimnisse im Klartext in den Chat ein. Die Reichweite von Claude wird durch den Geltungsbereich des Schlüssels begrenzt, und jeder Tool-Aufruf wird protokolliert unter Organisationseinstellungen → MCP → Audit-Log für Tool-Aufrufe (DSGVO Art. 15).

Mit Ihren Modellen sprechen

Lesen und Vorschlagen heißt, betool zu konfigurieren. Eine externe KI kann es auch benutzen: eine echte Unterhaltung mit einem Ihrer Modelle führen, Zug um Zug, genau wie jeder Besucher in Ihrem Chat. Nützlich, um einen Assistenten von einer anderen KI auf die Probe stellen zu lassen, um betool hinter einen Partner-Agenten zu setzen, oder um ein internes Werkzeug einen Ihrer Prozesse in natürlicher Sprache befragen zu lassen.

Vier Tools: conversation.open öffnet oder findet eine Unterhaltung wieder, conversation.send sendet einen Zug und gibt die Antwort zurück, conversation.poll holt eine Antwort ab, die länger gedauert hat, conversation.history liest den Verlauf erneut. Diese Unterhaltung ist ein betool-Kontext wie jeder andere: Sie erscheint in Ihren Unterhaltungen, das Modell sieht die vorherigen Züge, und Sie lesen alles in der Oberfläche nach.

Die Erlaubnis gibt das Modell, nie der Schlüssel. Sie müssen den Empfänger Externer Agent am Start-Knoten des Modells deklarieren: ohne diese Deklaration wird der Aufruf abgewiesen, auch mit einem Schlüssel im Geltungsbereich Voll. Seit dieser Bereitstellung erstellte Modelle deklarieren ihn standardmäßig (der normale Weg ist der einfache Weg); ältere müssen ihn erhalten, und bei jedem lässt er sich entfernen. Es entscheidet also das Modell, nie der Schlüssel — und der Empfänger muss in der veröffentlichten Version vorhanden sein, der laufenden. Und weil ein Zug echte Wirkungen auslösen kann — eine E-Mail geht raus, ein Datensatz entsteht —, verbraucht er die Credits der Organisation und wird wie jeder Tool-Aufruf protokolliert.

Eine Antwort geht nie verloren: Arbeitet das Modell länger als die zugestandene Wartezeit, gibt der Aufruf ein Ticket zurück und der Zug läuft serverseitig weiter — er übersteht sogar ein Redeployment. Die Anwendung holt die Antwort dann mit conversation.poll. Die Nachricht erneut zu senden beschleunigt nichts — und während der Zug läuft, wird das Senden abgewiesen.

Und schließlich liest dieser Kanal nur seine eigenen Unterhaltungen. Eine Kontext-ID aus einem anderen Eingang — öffentlicher Chat, Telefon, E-Mail — ist hier nicht lesbar: die Gespräche Ihrer Kunden werden nicht einsehbar, nur weil eine MCP-Anwendung verbunden ist.

Ein bereits bestehendes Modell funktioniert unverändert. Dieser Kanal setzt dieselben Schlüssel wie ein Chat: die Nachricht landet in user_message, und das Ereignis ist ein gewöhnliches on_message — Ihre Filter und die Auswahlen Ihrer Agenten funktionieren also weiter. Wurde das Zielmodell für einen anderen Eingang geschrieben (es liest telegram.text, ein Ziel, eine Seitenvariable…), kann die Anwendung diese Schlüssel selbst über variables mitgeben: sie gelangen genau dorthin in den Fluss, wo der andere Eingang sie gesetzt hätte. Was sie nicht fälschen kann, ist die Identität des Zuges — wer gesprochen hat und über welchen Kanal: diese Schlüssel setzt der Server, und jeder Versuch wird abgewiesen und in der Antwort gemeldet.

Bleibt das Modell stumm, prüfen Sie sein Routing. Ein Modell, das mehrere Kanäle bedient, verzweigt meist über den Eingang (filter input.entry_kind == chat_widget…): ein Zug mit dem Eingang « externer Agent » trifft dann keinen Zweig, und nichts antwortet — ohne jeden Fehler. Übergeben Sie as_entry_kind, um wie dieser Kanal geroutet zu werden. Es ändert nur den Routing-Schlüssel: Kanalbeschreibung und Audit-Protokoll sagen weiterhin, dass der Zug von einer externen KI kam, und die echten Kanalfähigkeiten gelten unverändert.

Eine Unterhaltung bearbeitet einen Zug auf einmal. Solange der vorherige Zug seine Antwort nicht geliefert hat, wird der nächste abgewiesen — mit der Angabe, welcher Zug zu lesen ist. Keine willkürliche Grenze: eine Antwort hängt über ihre Position im Verlauf an ihrer Frage, zwei Züge gleichzeitig machten die Zuordnung also unklar — eine klare Abweisung ist besser als eine plausible, falsche Antwort.

Eine Anwendung eines Dritten verbinden (OAuth 2.1)

Ein Schlüssel im Header passt zu Claude Code. Andere Clients — Claude Desktop, ChatGPT, ein Editor, Ihre eigene Anwendung — verbinden sich über OAuth 2.1 + PKCE, ohne dass jemand ein Geheimnis handhabt. Es ist nichts vorzubereiten: kein Client anzumelden, keine Kennung bei uns anzufordern.

Für die Nutzerin sind es drei Bildschirme:

Fügen Sie in der Anwendung den MCP-Server https://platform.betool.ai/mcp hinzu.
Ihr Browser öffnet einen betool-Zustimmungsbildschirm: Er nennt die Anwendung, die Zugriff verlangt, die betroffene Organisation und wohin die Rückkehr erfolgt. Prüfen Sie diese drei Angaben — besonders wenn Sie mehreren Organisationen angehören.
Wählen Sie den Geltungsbereich, den Sie erteilen, und dann Autorisieren. Die Anwendung erhält nie mehr, als Sie ankreuzen, selbst wenn sie mehr verlangt hat.

Nur ein Administrator der Organisation kann eine Anwendung autorisieren. Eine Anwendung zu verbinden schafft dauerhafte Autorität über die gesamte Organisation — genau das, was ein MCP-Schlüssel ist. Ein Mitglied mit eingeschränkten Rechten kann seine Beschränkungen über diesen Weg also nicht umgehen.

Für Integratoren läuft die Erkennung vollautomatisch und standardkonform: Ein nicht authentifizierter Aufruf von /mcp liefert ein 401 mit dem Header WWW-Authenticate und der Adresse unserer Metadaten (RFC 9728), die wiederum auf Autorisierung, Token-Austausch, dynamische Client-Registrierung (RFC 7591) und Widerruf (RFC 7009) verweisen. PKCE S256 ist Pflicht, Access-Tokens gelten eine Stunde, und das Refresh-Token rotiert bei jeder Verwendung.

# Was ein Client von selbst tut — praktisch zur Prüfung im Terminal.
curl -i -X POST https://platform.betool.ai/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'
# -> 401 + WWW-Authenticate: Bearer ... resource_metadata="..."

curl -s https://platform.betool.ai/.well-known/oauth-authorization-server

Ein Token ist nur für betool gültig: anderswo eingesetzt, wird es abgelehnt (RFC 8707). Und wird ein bereits verbrauchtes Refresh-Token ein zweites Mal vorgelegt — das Kennzeichen eines gestohlenen Tokens — wird die gesamte Sitzung widerrufen, und die Nutzerin muss erneut autorisieren.

Verbundene Anwendungen: einsehen und trennen

Unter Organisationseinstellungen → MCP listet der Abschnitt Verbundene Anwendungen auf, was mit Ihrer Organisation verbunden ist: Name der Anwendung, erteilter Geltungsbereich, wer sie autorisiert hat und wann sie zuletzt genutzt wurde. Eine Schaltfläche Trennen kappt den Zugriff sofort — alle Tokens dieser Anwendung, ausschließlich für Ihre Organisation.

Dieselbe Anwendung kann von mehreren Organisationen verbunden sein: Sie bei sich zu trennen betrifft niemanden sonst. Eine Anwendung kann sich auch selbst trennen.

Geltungsbereich & Isolation

Standardmäßig operiert ein Schlüssel nur auf Ihrer eigenen Organisation — die Zielorganisation wird serverseitig erzwungen; Sie übergeben niemals eine Organisations-ID als Argument.
Anbieterschlüssel (Backoffice-Organisation) können auf eine andere Organisation abzielen, mit der ausdrücklichen Zustimmung dieser Organisation und mit vollständigem Audit — nützlich für einen mandantenfähigen Anbieter-Anwendungsfall.

Audit-Protokoll

Jeder Tool-Aufruf (extern über MCP und intern) schreibt eine Audit-Zeile: wer, welches Tool, welcher Kanal, welcher Geltungsbereich, Ergebnis, Latenz. Verfügbar unter Organisationseinstellungen → MCP (Abschnitt Audit-Log für Tool-Aufrufe), strikt auf Ihre Organisation begrenzt.

Siehe auch

Admin-API — automatisieren Sie betool aus Ihren eigenen Systemen heraus.
Sicherheit & Compliance — das Governance-Modell für Vorschläge.