betool von Claude aus steuern (MCP-Server)

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.

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.
• 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.

Einen MCP-Schlüssel erstellen

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

1. Öffnen Sie in betool Einstellungen → MCP.
2. 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.
3. 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.

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.

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:

1. Fügen Sie in der Anwendung den MCP-Server https://platform.betool.ai/mcp hinzu.
2. 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.
3. 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.

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 Einstellungen → 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 Einstellungen → MCP, strikt auf Ihre Organisation begrenzt.

Demnächst

• Feingranulare, tool-spezifische Steuerung der über MCP freigegebenen Oberfläche.
• Server→Client-Stream (SSE) für Server-Benachrichtigungen.

Siehe auch

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