Skip to main content
openclaw mcp hat zwei Aufgaben:
  • OpenClaw mit openclaw mcp serve als MCP-Server ausführen
  • von OpenClaw verwaltete Definitionen ausgehender MCP-Server mit list, show, status, doctor, probe, add, set, configure, tools, login, logout, reload und unset verwalten
Bei serve fungiert OpenClaw als MCP-Server. Bei den anderen Unterbefehlen fungiert OpenClaw als clientseitige MCP-Registry für Server, die seine eigenen Laufzeitumgebungen später verwenden können.
list, show, set und unset lesen und schreiben ausschließlich von OpenClaw verwaltete mcp.servers-Einträge in der OpenClaw-Konfiguration. Sie enthalten keine mcporter-Server aus config/mcporter.json; verwenden Sie für diese Registry mcporter list.
Verwenden Sie openclaw acp, wenn OpenClaw selbst eine Coding-Harness-Sitzung hosten und diese Laufzeitumgebung über ACP leiten soll.

Den richtigen MCP-Pfad auswählen

Wenn Sie nicht sicher sind, welchen Pfad Sie benötigen, beginnen Sie mit openclaw mcp status --verbose. Damit wird angezeigt, was OpenClaw gespeichert hat, ohne MCP-Server zu starten.

OpenClaw als MCP-Server

Dies ist der Pfad openclaw mcp serve.

Wann serve verwendet werden sollte

Verwenden Sie openclaw mcp serve, wenn:
  • Codex, Claude Code oder ein anderer MCP-Client direkt mit von OpenClaw gestützten Kanalunterhaltungen kommunizieren soll
  • bereits ein lokales oder entferntes OpenClaw Gateway mit weitergeleiteten Sitzungen vorhanden ist
  • Sie einen MCP-Server wünschen, der über die Kanal-Backends von OpenClaw hinweg funktioniert, anstatt separate Bridges für jeden Kanal auszuführen
Verwenden Sie stattdessen openclaw acp, wenn OpenClaw die Coding-Laufzeitumgebung selbst hosten und die Agentensitzung innerhalb von OpenClaw halten soll.

Funktionsweise

openclaw mcp serve startet einen stdio-MCP-Server. Der MCP-Client ist Eigentümer dieses Prozesses. Solange der Client die stdio-Sitzung geöffnet hält, stellt die Bridge über WebSocket eine Verbindung zu einem lokalen oder entfernten OpenClaw Gateway her und macht weitergeleitete Kanalunterhaltungen über MCP verfügbar.
1

Client startet die Bridge

Der MCP-Client startet openclaw mcp serve.
2

Bridge verbindet sich mit dem Gateway

Die Bridge stellt über WebSocket eine Verbindung zum OpenClaw Gateway her.
3

Sitzungen werden zu MCP-Unterhaltungen

Weitergeleitete Sitzungen werden zu MCP-Unterhaltungen und Transkript-/Verlaufswerkzeugen.
4

Live-Ereignisse werden in die Warteschlange gestellt

Live-Ereignisse werden im Arbeitsspeicher in eine Warteschlange gestellt, während die Bridge verbunden ist.
5

Optionaler Claude-Push

Wenn der Claude-Kanalmodus aktiviert ist, kann dieselbe Sitzung auch Claude-spezifische Push-Benachrichtigungen empfangen.
  • der Zustand der Live-Warteschlange beginnt, wenn die Bridge die Verbindung herstellt
  • älterer Transkriptverlauf wird mit messages_read gelesen
  • Claude-Push-Benachrichtigungen existieren nur, solange die MCP-Sitzung aktiv ist
  • wenn der Client die Verbindung trennt, wird die Bridge beendet und die Live-Warteschlange geht verloren
  • einmalige Agenteneinstiegspunkte wie openclaw agent und openclaw infer model run beenden alle gebündelten MCP-Laufzeitumgebungen, die sie öffnen, sobald die Antwort abgeschlossen ist, sodass sich bei wiederholten skriptgesteuerten Ausführungen keine stdio-MCP-Unterprozesse ansammeln
  • von OpenClaw gestartete stdio-MCP-Server (gebündelt oder benutzerkonfiguriert) werden beim Herunterfahren als Prozessbaum beendet, sodass vom Server gestartete untergeordnete Prozesse nach dem Beenden des übergeordneten stdio-Clients nicht weiterlaufen
  • durch das Löschen oder Zurücksetzen einer Sitzung werden die MCP-Clients dieser Sitzung über den gemeinsamen Bereinigungspfad der Laufzeitumgebung freigegeben, sodass keine verbleibenden stdio-Verbindungen an eine entfernte Sitzung gebunden sind

Clientmodus auswählen

Nur standardmäßige MCP-Werkzeuge. Verwenden Sie conversations_list, messages_read, events_poll, events_wait, messages_send und die Genehmigungswerkzeuge.
Derzeit verhält sich auto genauso wie on. Eine Erkennung der Clientfähigkeiten ist noch nicht vorhanden.

Von serve bereitgestellte Funktionen

Die Bridge verwendet vorhandene Routenmetadaten der Gateway-Sitzung, um kanalgestützte Unterhaltungen bereitzustellen. Eine Unterhaltung erscheint, wenn OpenClaw bereits über einen Sitzungszustand mit einer bekannten Route wie der folgenden verfügt:
  • channel
  • Empfänger- oder Zielmetadaten
  • optional accountId
  • optional threadId
Dadurch erhalten MCP-Clients eine zentrale Stelle, um:
  • kürzlich weitergeleitete Unterhaltungen aufzulisten
  • den aktuellen Transkriptverlauf zu lesen
  • auf neue eingehende Ereignisse zu warten
  • eine Antwort über dieselbe Route zurückzusenden
  • Genehmigungsanfragen zu sehen, die eintreffen, während die Bridge verbunden ist

Verwendung

Bridge-Werkzeuge

Listet aktuelle sitzungsgestützte Unterhaltungen auf, die bereits über Routenmetadaten im Gateway-Sitzungszustand verfügen.Filter: limit (max. 500), search, channel, includeDerivedTitles, includeLastMessage.
Gibt eine Unterhaltung anhand von session_key mithilfe einer direkten Gateway-Sitzungssuche zurück.
Liest aktuelle Transkriptnachrichten für eine sitzungsgestützte Unterhaltung. limit ist standardmäßig 20, maximal 200.
Extrahiert nicht textbasierte Nachrichteninhaltsblöcke aus einer Transkriptnachricht. Dies ist eine Metadatenansicht des Transkriptinhalts und kein eigenständiger dauerhafter Blob-Speicher für Anhänge.
Liest seit einem numerischen Cursor in die Warteschlange gestellte Live-Ereignisse. limit maximal 200.
Führt Long-Polling durch, bis das nächste passende Ereignis in der Warteschlange eintrifft oder ein Timeout abläuft (standardmäßig 30s, maximal 300s).Verwenden Sie dies, wenn ein generischer MCP-Client eine nahezu in Echtzeit erfolgende Zustellung ohne Claude-spezifisches Push-Protokoll benötigt.
Sendet Text über dieselbe Route zurück, die bereits in der Sitzung aufgezeichnet wurde.Aktuelles Verhalten:
  • erfordert eine vorhandene Unterhaltungsroute
  • verwendet den Kanal, den Empfänger, die Konto-ID und die Thread-ID der Sitzung
  • sendet ausschließlich Text
Listet ausstehende Ausführungs-/Plugin-Genehmigungsanfragen auf, die die Bridge seit ihrer Verbindung mit dem Gateway beobachtet hat.
Bearbeitet eine ausstehende Ausführungs-/Plugin-Genehmigungsanfrage mit:
  • allow-once
  • allow-always
  • deny

Ereignismodell

Die Bridge führt eine Ereigniswarteschlange im Arbeitsspeicher, solange sie verbunden ist. Aktuelle Ereignistypen:
  • message
  • exec_approval_requested
  • exec_approval_resolved
  • plugin_approval_requested
  • plugin_approval_resolved
  • claude_permission_request
  • die Warteschlange enthält nur Live-Daten; sie beginnt beim Start der MCP-Bridge
  • events_poll und events_wait geben älteren Gateway-Verlauf nicht selbstständig erneut wieder
  • dauerhafter Rückstand sollte mit messages_read gelesen werden

Claude-Kanalbenachrichtigungen

Die Bridge kann außerdem Claude-spezifische Kanalbenachrichtigungen bereitstellen. Dies ist das OpenClaw-Äquivalent eines Claude-Code-Kanaladapters: Standardmäßige MCP-Werkzeuge bleiben verfügbar, eingehende Live-Nachrichten können jedoch auch als Claude-spezifische MCP-Benachrichtigungen eintreffen.
--claude-channel-mode off: nur standardmäßige MCP-Werkzeuge.
Wenn der Claude-Kanalmodus aktiviert ist, kündigt der Server experimentelle Claude-Fähigkeiten an und kann Folgendes ausgeben:
  • notifications/claude/channel
  • notifications/claude/channel/permission
Aktuelles Bridge-Verhalten:
  • eingehende user-Transkriptnachrichten werden als notifications/claude/channel weitergeleitet
  • über MCP empfangene Claude-Berechtigungsanfragen werden im Arbeitsspeicher nachverfolgt
  • wenn der Befehlseigentümer in der verknüpften Unterhaltung später yes <id> oder no <id> sendet (<id> ist die fünfstellige Anfrage-ID ohne l), wandelt die Bridge dies in notifications/claude/channel/permission um
  • diese Benachrichtigungen sind ausschließlich für die Live-Sitzung bestimmt; wenn der MCP-Client die Verbindung trennt, gibt es kein Push-Ziel
Dies ist bewusst clientspezifisch. Generische MCP-Clients sollten die standardmäßigen Polling-Werkzeuge verwenden.

MCP-Client-Konfiguration

Beispiel für eine stdio-Client-Konfiguration:
Beginnen Sie bei den meisten generischen MCP-Clients mit der standardmäßigen Tool-Oberfläche und ignorieren Sie den Claude-Modus. Aktivieren Sie den Claude-Modus nur für Clients, die die Claude-spezifischen Benachrichtigungsmethoden tatsächlich verstehen.

Optionen

openclaw mcp serve unterstützt:
string
Gateway-WebSocket-URL. Verwendet standardmäßig gateway.remote.url, wenn dies konfiguriert ist.
string
Gateway-Token.
string
Token aus einer Datei lesen.
string
Gateway-Passwort.
string
Passwort aus einer Datei lesen.
"auto" | "on" | "off"
Claude-Benachrichtigungsmodus. Standardwert: auto.
boolean
Ausführliche Protokolle auf stderr.
Verwenden Sie nach Möglichkeit --token-file oder --password-file anstelle eingebetteter Geheimnisse.

Sicherheits- und Vertrauensgrenze

Die Bridge erfindet kein Routing. Sie macht nur Konversationen zugänglich, für die das Gateway bereits Routing unterstützt. Das bedeutet:
  • Absender-Zulassungslisten, Kopplung und Vertrauen auf Kanalebene gehören weiterhin zur zugrunde liegenden OpenClaw-Kanalkonfiguration
  • messages_send kann nur über eine vorhandene gespeicherte Route antworten
  • der Genehmigungsstatus ist nur live/im Arbeitsspeicher für die aktuelle Bridge-Sitzung verfügbar
  • die Bridge-Authentifizierung sollte dieselben Gateway-Token- oder Passwortkontrollen verwenden, denen Sie auch bei jedem anderen entfernten Gateway-Client vertrauen würden
Wenn eine Konversation in conversations_list fehlt, liegt die Ursache normalerweise nicht an der MCP-Konfiguration. Es fehlen Routing-Metadaten in der zugrunde liegenden Gateway-Sitzung oder sie sind unvollständig.

Tests

OpenClaw enthält einen deterministischen Docker-Smoke-Test für diese Bridge:
Dieser Smoke-Test führt einen einzelnen Container aus: Er initialisiert den Konversationsstatus, startet das Gateway, erzeugt dann openclaw mcp serve als stdio-Kindprozess und steuert ihn als MCP-Client. Er überprüft die Konversationserkennung, das Lesen von Transkripten, das Lesen von Anhangsmetadaten, das Verhalten der Live-Ereigniswarteschlange sowie Kanal- und Berechtigungsbenachrichtigungen im Claude-Stil über die echte stdio-MCP-Bridge. Das Routing ausgehender Sendungen (messages_send, das die gespeicherte Konversationsroute wiederverwendet) wird separat durch Unit-Tests in src/mcp/channel-server.test.ts abgedeckt. Dies ist der schnellste Weg, die Funktionsfähigkeit der Bridge nachzuweisen, ohne ein echtes Telegram-, Discord- oder iMessage-Konto in den Testlauf einzubinden. Einen umfassenderen Testkontext finden Sie unter Tests.

Fehlerbehebung

Dies bedeutet normalerweise, dass die Gateway-Sitzung noch kein Routing ermöglicht. Vergewissern Sie sich, dass für die zugrunde liegende Sitzung Kanal/Provider, Empfänger sowie optionale Routing-Metadaten für Konto/Thread gespeichert sind.
Dies ist zu erwarten. Die Live-Warteschlange beginnt, wenn die Bridge die Verbindung herstellt. Lesen Sie den älteren Transkriptverlauf mit messages_read.
Prüfen Sie Folgendes:
  • der Client hat die stdio-MCP-Sitzung geöffnet gehalten
  • --claude-channel-mode ist on oder auto
  • der Client versteht tatsächlich die Claude-spezifischen Benachrichtigungsmethoden
  • die eingehende Nachricht ist nach dem Verbindungsaufbau der Bridge eingegangen
permissions_list_open zeigt nur Genehmigungsanfragen an, die beobachtet wurden, während die Bridge verbunden war. Es handelt sich nicht um eine API für einen dauerhaften Genehmigungsverlauf.

OpenClaw als MCP-Client-Registrierung

Dies ist der Pfad für openclaw mcp list, show, status, doctor, probe, add, set, configure, tools, login, logout, reload und unset. Diese Befehle machen OpenClaw nicht über MCP zugänglich. Sie verwalten von OpenClaw verwaltete MCP-Serverdefinitionen unter mcp.servers in der OpenClaw-Konfiguration. Sie lesen keine mcporter-Server aus config/mcporter.json. Diese gespeicherten Definitionen sind für Laufzeitumgebungen vorgesehen, die OpenClaw später startet oder konfiguriert, beispielsweise eingebettetes OpenClaw und andere Laufzeitadapter. OpenClaw speichert die Definitionen zentral, damit diese Laufzeitumgebungen keine eigenen doppelten MCP-Serverlisten verwalten müssen.
  • diese Befehle lesen oder schreiben ausschließlich die OpenClaw-Konfiguration
  • status, list, show, doctor ohne --probe, set, configure, tools, logout, reload und unset stellen keine Verbindung zum MCP-Zielserver her
  • login führt den MCP-OAuth-Netzwerkablauf für den konfigurierten HTTP-Server aus und speichert die resultierenden lokalen Anmeldedaten
  • status --verbose gibt aufgelöste Hinweise zu Transport, Authentifizierung, Zeitüberschreitung, Filter und parallelen Tool-Aufrufen aus, ohne eine Verbindung herzustellen
  • doctor prüft gespeicherte Definitionen auf lokale Einrichtungsprobleme wie fehlende stdio-Befehle, ungültige Arbeitsverzeichnisse, fehlende TLS-Dateien, deaktivierte Server, sensible Header-/Umgebungswerte im Klartext und unvollständige OAuth-Autorisierung
  • doctor --probe ergänzt nach erfolgreichen statischen Prüfungen denselben Nachweis einer Live-Verbindung wie probe
  • probe stellt eine Verbindung zum ausgewählten Server oder zu allen konfigurierten Servern her, listet Tools auf und meldet Funktionen/Diagnosen
  • add erstellt anhand von Flags eine Definition und prüft sie vor dem Speichern, sofern nicht --no-probe gesetzt ist oder zuerst eine OAuth-Autorisierung erforderlich ist
  • Laufzeitadapter entscheiden zur Ausführungszeit, welche Transportformen sie tatsächlich unterstützen
  • enabled: false behält einen Server gespeichert bei, schließt ihn jedoch von der Erkennung durch eingebettete Laufzeitumgebungen aus
  • requestTimeoutMs und connectionTimeoutMs legen Zeitüberschreitungen pro Server für Anfragen und Verbindungen in Millisekunden fest
  • supportsParallelToolCalls: true kennzeichnet Server, die Adapter gleichzeitig aufrufen können
  • HTTP-Server können statische Header, OAuth-Anmeldung, Steuerung der TLS-Verifizierung sowie mTLS-Zertifikat-/Schlüsselpfade verwenden
  • eingebettetes OpenClaw stellt konfigurierte MCP-Tools in den normalen Tool-Profilen coding und messaging bereit; minimal blendet sie weiterhin aus und tools.deny: ["bundle-mcp"] deaktiviert sie ausdrücklich
  • toolFilter.include und toolFilter.exclude pro Server filtern erkannte MCP-Tools, bevor sie zu OpenClaw-Tools werden
  • Server, die Ressourcen oder Prompts ankündigen, stellen auch Hilfstools zum Auflisten/Lesen von Ressourcen und zum Auflisten/Abrufen von Prompts bereit; diese generierten Namen der Hilfstools (resources_list, resources_read, prompts_list, prompts_get) verwenden denselben Einschluss-/Ausschlussfilter
  • dynamische Änderungen der MCP-Tool-Liste machen den zwischengespeicherten Katalog für diese Sitzung ungültig; bei der nächsten Erkennung/Verwendung wird er vom Server aktualisiert
  • wiederholte Fehler bei MCP-Tool-Anfragen oder im Protokoll pausieren diesen Server kurzzeitig, damit ein einzelner defekter Server nicht den gesamten Durchlauf beansprucht
  • sitzungsbezogene gebündelte MCP-Laufzeitumgebungen werden nach 10 Minuten Inaktivität beendet, und einmalige eingebettete Durchläufe bereinigen sie am Ende des Durchlaufs
Laufzeitadapter können diese gemeinsame Registrierung in die Form normalisieren, die ihr nachgelagerter Client erwartet. Beispielsweise verwendet eingebettetes OpenClaw OpenClaw-Werte vom Typ transport direkt, während Claude Code und Gemini CLI-native Werte vom Typ type wie http, sse oder stdio erhalten. Der Codex-App-Server berücksichtigt außerdem einen optionalen codex-Block auf jedem Server. Dabei handelt es sich ausschließlich um OpenClaw-Projektionsmetadaten für Codex-App-Server-Threads; sie ändern weder ACP-Sitzungen noch die generische Codex-Harness-Konfiguration oder andere Laufzeitadapter. Verwenden Sie ein nicht leeres codex.agents, um einen Server nur in bestimmte OpenClaw- Agent-IDs zu projizieren. Leere, ausschließlich aus Leerzeichen bestehende oder ungültige Agentenlisten werden von der Konfigurations- validierung abgelehnt und vom Projektionspfad der Laufzeitumgebung weggelassen, anstatt global zu werden. Verwenden Sie codex.defaultToolsApprovalMode (auto, prompt oder approve), um das native default_tools_approval_mode von Codex für einen vertrauenswürdigen Server auszugeben. OpenClaw entfernt die codex-Metadaten, bevor es die native mcp_servers- Konfiguration an Codex übergibt.

Gespeicherte MCP-Serverdefinitionen

Befehle:
  • openclaw mcp list
  • openclaw mcp show [name]
  • openclaw mcp status [--verbose]
  • openclaw mcp doctor [name] [--probe]
  • openclaw mcp probe [name]
  • openclaw mcp add <name> [flags]
  • openclaw mcp set <name> <json>
  • openclaw mcp configure <name> [flags]
  • openclaw mcp tools <name> [--include csv] [--exclude csv] [--clear]
  • openclaw mcp login <name> [--code code]
  • openclaw mcp logout <name>
  • openclaw mcp reload
  • openclaw mcp unset <name>
Hinweise:
  • list sortiert Servernamen.
  • show ohne Namen gibt das vollständige konfigurierte MCP-Serverobjekt aus.
  • status klassifiziert konfigurierte Transporte, ohne eine Verbindung herzustellen. --verbose enthält aufgelöste Details zu Start, Zeitüberschreitung, OAuth, Filter und parallelen Aufrufen, einschließlich der Fälle, in denen gespeicherte OAuth-Token eine zusätzliche Autorisierung erfordern. stdio-Argumente, die Anmeldedaten enthalten, werden in der Text- und JSON-Ausgabe geschwärzt.
  • doctor führt statische Prüfungen durch, ohne eine Verbindung herzustellen. Fügen Sie --probe hinzu, wenn der Befehl zusätzlich überprüfen soll, ob aktivierte Server eine Verbindung herstellen können.
  • probe stellt eine Verbindung her und meldet die Anzahl der Tools, die Unterstützung von Ressourcen/Prompts, die Unterstützung von Listenänderungen und Diagnosen.
  • add akzeptiert stdio-Flags wie --command, --arg, --env und --cwd oder HTTP-Flags wie --url, --transport, --header, --auth oauth sowie Flags für TLS, Zeitüberschreitung und Tool-Auswahl.
  • set erwartet einen einzelnen JSON-Objektwert in der Befehlszeile.
  • configure aktualisiert Aktivierung, Tool-Filter, Zeitüberschreitungen, OAuth, TLS und Hinweise zu parallelen Tool-Aufrufen, ohne die gesamte Serverdefinition zu ersetzen. Fügen Sie --probe hinzu, um den aktualisierten Server vor dem Speichern zu überprüfen.
  • tools aktualisiert Tool-Filter pro Server. Einschluss-/Ausschlusseinträge sind MCP-Tool-Namen und einfache *-Globs.
  • login führt den OAuth-Ablauf für HTTP-Server aus, die mit auth: "oauth" konfiguriert sind. Der erste Durchlauf gibt eine Autorisierungs-URL aus; führen Sie den Befehl nach der Genehmigung erneut mit --code aus.
  • logout löscht gespeicherte OAuth-Anmeldedaten für den benannten Server, ohne die gespeicherte Serverdefinition zu entfernen.
  • reload verwirft zwischengespeicherte prozessinterne MCP-Laufzeitumgebungen ausschließlich für den aktuellen CLI-Prozess. Gateway- oder Agentenprozesse in einem anderen Prozess benötigen weiterhin einen eigenen Neu-Lade- oder Neustartpfad.
  • Verwenden Sie transport: "streamable-http" für Streamable-HTTP-MCP-Server. openclaw mcp set normalisiert außerdem das CLI-native type: "http" aus Kompatibilitätsgründen in dieselbe kanonische Konfigurationsform.
  • unset schlägt fehl, wenn der benannte Server nicht existiert.
Beispiele:

Gängige Serverkonfigurationen

Diese Beispiele speichern nur Serverdefinitionen. Führen Sie anschließend openclaw mcp doctor --probe aus, um nachzuweisen, dass der Server startet und Tools bereitstellt.
Beschränken Sie Dateisystemserver auf den kleinsten Verzeichnisbaum, den der Agent lesen oder bearbeiten soll.

JSON-Ausgabeformate

Verwenden Sie --json für Skripte und Dashboards. Feldmengen können mit der Zeit erweitert werden, daher sollten Konsumenten unbekannte Schlüssel ignorieren.
doctor --json wird mit einem von null verschiedenen Status beendet, wenn ein aktivierter, geprüfter Server ein Problem der Stufe error aufweist. Probleme der Stufen warning und info werden gemeldet, führen für sich genommen jedoch nicht zum Fehlschlagen des Befehls.
probe --json öffnet eine aktive MCP-Clientsitzung und gibt ihr Ergebnis direkt aus; anders als bei status/doctor enthält die Ausgabe kein path-Feld auf oberster Ebene. Die Schlüssel resources und prompts sind nur vorhanden, wenn der Server die jeweilige Fähigkeit tatsächlich ankündigt (ein Server ohne Prompts lässt den Schlüssel prompts weg, statt false zu melden). Verwenden Sie probe zum Nachweis der Erreichbarkeit und Fähigkeiten, nicht für statische Konfigurationsprüfungen.
Beispiel für die Konfigurationsstruktur:

Stdio-Transport

Startet einen lokalen untergeordneten Prozess und kommuniziert über stdin/stdout.
Sicherheitsfilter für die Stdio-UmgebungOpenClaw weist vor dem Start eines Stdio-MCP-Servers Umgebungsschlüssel zurück, die den Interpreterstart, das Einschleusen von Loadern oder die Shellinitialisierung beeinflussen, selbst wenn sie im env-Block eines Servers enthalten sind. Dabei wird dieselbe Sicherheitsrichtlinie für die Hostumgebung verwendet wie bei anderen von OpenClaw gestarteten Prozessen: Bekannte Hooks für den Interpreterstart (beispielsweise NODE_OPTIONS, PYTHONSTARTUP, PERL5OPT, RUBYOPT, BASHOPTS, KSH_ENV), Präfixe für gemeinsam verwendete Bibliotheken und Funktionseinschleusung (DYLD_*, LD_*, BASH_FUNC_*) sowie ähnliche Variablen zur Laufzeitsteuerung werden blockiert. Beim Start werden diese stillschweigend entfernt und eine Warnung wird protokolliert, damit sie kein implizites Präambel-Skript einschleusen, den Interpreter austauschen, einen Debugger aktivieren oder den dynamischen Linker des Stdio-Prozesses übernehmen können. Eine explizite Zulassungsliste sorgt dafür, dass gewöhnliche Umgebungsvariablen für MCP-Anmeldedaten weiterhin verwendet werden können (GITHUB_TOKEN, GH_TOKEN, GITLAB_TOKEN, NPM_TOKEN, NODE_AUTH_TOKEN, DATABASE_URL, MONGODB_URI, REDIS_URL, AMQP_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET), ebenso wie gewöhnliche Proxy- und serverspezifische Umgebungsvariablen (HTTP_PROXY, benutzerdefinierte *_API_KEY usw.). Andere AWS_*-Schlüssel wie AWS_CONFIG_FILE und AWS_SHARED_CREDENTIALS_FILE bleiben blockiert, da sie auf Anmeldedatendateien verweisen, statt direkt einen Anmeldedatenwert zu enthalten.Wenn Ihr MCP-Server tatsächlich eine der blockierten Variablen benötigt, legen Sie diese im Gateway-Hostprozess statt unter env des Stdio-Servers fest.

SSE-/HTTP-Transport

Stellt über HTTP Server-Sent Events eine Verbindung zu einem Remote-MCP-Server her. Beispiel:
Sensible Werte in url (Benutzerinformationen) und headers werden in Protokollen und Statusausgaben geschwärzt. openclaw mcp doctor warnt, wenn sensibel wirkende Einträge in headers oder env literale Werte enthalten, damit Betreiber diese Werte aus der committeten Konfiguration entfernen können.

OAuth-Ablauf

OAuth ist für HTTP-MCP-Server vorgesehen, die den MCP-OAuth-Ablauf ankündigen. Statische Authorization-Header werden für einen Server ignoriert, solange auth: "oauth" aktiviert ist. Von openclaw mcp login gespeicherte Anmeldedaten funktionieren mit eingebettetem MCP, CLI-Runnern und dem lokalen Codex-App-Server. Native MCP-OAuth-Sitzungen werden in der nur für den Eigentümer zugänglichen, gemeinsam verwendeten SQLite-Datenbank unter <state-dir>/state/openclaw.sqlite (mcp_oauth_stores) gespeichert. Die Zeile kann Zugriffs- und Aktualisierungstoken, Geheimnisse der dynamischen Clientregistrierung, Discovery-Metadaten und den temporären PKCE-Verifier enthalten. Aktualisierung, Anmeldung und Abmeldung verwenden dieselbe SQLite-Lease, sodass parallele OpenClaw-Prozesse nicht dasselbe Aktualisierungstoken verbrauchen oder eine abgemeldete Sitzung wiederherstellen können. Upgrades aus dem eingestellten <state-dir>/mcp-oauth/*.json-Speicher werden ausschließlich von openclaw doctor --fix verarbeitet. Der Laufzeitcode liest oder schreibt diese Dateien niemals und greift auch nicht ersatzweise auf sie zurück. Bis Anmeldedaten verfügbar sind, lässt OpenClaw nur diesen MCP-Server aus der Agentenlaufzeit aus, statt den Agentendurchlauf fehlschlagen zu lassen. Der Betreiber oder ein Agent mit Shellzugriff kann anschließend openclaw mcp login <name> ausführen und den Server in einem späteren Durchlauf verwenden. Wenn ein Server ein Token mit insufficient_scope ablehnt, behält OpenClaw den angeforderten Geltungsbereich bei und fordert openclaw mcp login <name> an, statt eine Aktualisierung zu wiederholen, die keinen neuen Geltungsbereich gewähren kann. Diese Anmeldung startet eine neue Autorisierungsanfrage und behält das vorherige Token bei, bis die Ersatzanmeldedaten gespeichert wurden. Wenn ein Remote-MCP-Dienst bereits durch ein separates, aktualisierungsfähiges OpenClaw-Authentifizierungsprofil gestützt wird, können Sie optional oauth.authProfileId festlegen. OpenClaw aktualisiert beide möglichen Anmeldedatenquellen vor der Laufzeitprojektion und übergibt nur das aktuelle Zugriffstoken an den nachgelagerten MCP-Client.
1

Server speichern

Fügen Sie den Server mit auth: "oauth" und optionalen OAuth-Metadaten hinzu oder aktualisieren Sie ihn.
Speichern Sie für einen durch ein Authentifizierungsprofil gestützten Bearer-Token die Profilbindung:
2

Anmeldung starten

Führen Sie die Anmeldung aus, um die Autorisierungsanfrage zu erstellen.
OpenClaw gibt die Autorisierungs-URL aus und speichert den temporären OAuth-Verifizierungsstatus im gemeinsam genutzten SQLite.
3

Mit dem Code abschließen

Übergeben Sie nach der Genehmigung im Browser den zurückgegebenen Code an OpenClaw.
4

Autorisierung prüfen

Verwenden Sie den Status oder Doctor, um zu bestätigen, dass Tokens vorhanden sind und keine zusätzliche Autorisierung erforderlich ist. Wenn der Status authorization-required meldet oder Doctor eine zusätzliche Autorisierung anfordert, führen Sie openclaw mcp login <name> erneut aus.
5

Anmeldedaten löschen

Die Abmeldung entfernt gespeicherte OAuth-Anmeldedaten, behält jedoch die gespeicherte Serverdefinition bei.
Wenn der Provider Tokens rotiert oder der Autorisierungsstatus nicht mehr fortschreitet, führen Sie openclaw mcp logout <name> aus und wiederholen Sie anschließend login. logout kann Anmeldedaten für einen gespeicherten HTTP-Server auch dann löschen, wenn auth: "oauth" bereits aus der Konfiguration entfernt wurde, solange der Servername und die URL den Eintrag im Anmeldedatenspeicher weiterhin identifizieren.

Streamable-HTTP-Transport

streamable-http ist neben sse und stdio eine zusätzliche Transportoption. Sie verwendet HTTP-Streaming für die bidirektionale Kommunikation mit entfernten MCP-Servern. Die OpenClaw-Konfiguration verwendet transport: "streamable-http" als kanonische Schreibweise. CLI-native MCP-Werte für type: "http" werden akzeptiert, wenn sie über openclaw mcp set gespeichert werden, und in vorhandenen Konfigurationen durch openclaw doctor --fix korrigiert. Das eingebettete OpenClaw verarbeitet jedoch transport direkt. Beispiel:
Registrierungsbefehle starten die Kanal-Bridge nicht. Nur probe und doctor --probe öffnen eine aktive MCP-Clientsitzung, um nachzuweisen, dass der Zielserver erreichbar ist.

Control UI

Die browserbasierte Control UI enthält unter /settings/mcp eine eigene MCP-Einstellungsseite; der bisherige Pfad /mcp bleibt als Alias erhalten. Die Seite zeigt die Anzahl konfigurierter Server, Zusammenfassungen zu Aktivierung, OAuth und Filtern, Transportzeilen pro Server, Steuerelemente zum Aktivieren und Deaktivieren, gängige CLI-Befehle sowie einen bereichsspezifischen Editor für den Konfigurationsabschnitt mcp. Verwenden Sie die Seite für Änderungen durch Bedienpersonal und einen schnellen Überblick. Verwenden Sie openclaw mcp doctor --probe oder openclaw mcp probe, wenn Sie einen Live-Nachweis für den Server benötigen. Arbeitsablauf für Bedienpersonal:
  1. Öffnen Sie die Control UI und wählen Sie MCP.
  2. Prüfen Sie die Übersichtskarten für alle, aktivierte, OAuth- und gefilterte Server.
  3. Verwenden Sie jede Serverzeile für Hinweise zu Transport, Authentifizierung, Filtern, Timeouts und Befehlen.
  4. Schalten Sie die Aktivierung um, wenn Sie eine Definition beibehalten, sie jedoch von der Laufzeiterkennung ausschließen möchten.
  5. Bearbeiten Sie den bereichsspezifischen Konfigurationsabschnitt mcp, um strukturelle Änderungen wie neue Server, Header, TLS, OAuth-Metadaten oder Toolfilter vorzunehmen.
  6. Wählen Sie Save, um nur die Konfiguration dauerhaft zu speichern, oder Save & Publish, um sie über den Gateway-Konfigurationspfad anzuwenden.
  7. Führen Sie openclaw mcp doctor --probe aus, wenn Sie einen Live-Nachweis benötigen, dass der bearbeitete Server startet und Tools auflistet.
Hinweise:
  • Befehlsausschnitte setzen Servernamen in Anführungszeichen, damit ungewöhnliche Namen in einer Shell weiterhin kopiert werden können
  • angezeigte URL-ähnliche Werte werden vor der Darstellung geschwärzt, wenn sie eingebettete Anmeldedaten enthalten
  • die Seite startet MCP-Transporte nicht selbst
  • aktive Laufzeiten benötigen möglicherweise openclaw mcp reload, eine Veröffentlichung der Gateway-Konfiguration oder einen Prozessneustart, je nachdem, welcher Prozess die MCP-Clients verwaltet

MCP Apps

OpenClaw kann Tools darstellen, die die stabile MCP-Apps-Erweiterung implementieren. Apps müssen ausdrücklich aktiviert werden, da ihr HTML vom konfigurierten MCP-Server stammt und für Apps sichtbare Tools oder Ressourcen von demselben Server anfordern kann. Aktivieren Sie die Host-Bridge:
Starten Sie den Gateway nach Änderung dieser Einstellung neu. Wenn die Funktion aktiviert ist, startet OpenClaw einen ausschließlich für die Sandbox bestimmten HTTP(S)-Listener auf dem Gateway-Port plus eins (beim Standard-Gateway 18790). Die Control UI lädt Apps von diesem separaten Origin; der Listener stellt niemals die Control UI, authentifizierte Gateway-Routen oder Benutzerdaten bereit. Direkte Gateway-Verbindungen benötigen Zugriff auf beide Ports. Wenn ein Reverse-Proxy oder TLS-Terminator die Control UI bereitstellt, weisen Sie Apps einen eigenen öffentlichen Origin zu und leiten Sie ausschließlich diesen Origin an den Sandbox-Listener weiter:
Der Sandbox-Origin muss sich vom Origin der Control UI unterscheiden. Hosten Sie dort keine anderen authentifizierten oder vertraulichen Inhalte. Das offizielle einfache React-Demo kann beispielsweise wie folgt konfiguriert werden:
Verhaltens- und Sicherheitsgrenzen:
  • OpenClaw kündigt die Erweiterung io.modelcontextprotocol/ui nur an, wenn Apps aktiviert sind.
  • Nur Ressourcen vom Typ ui:// mit dem exakten MIME-Typ text/html;profile=mcp-app werden dargestellt.
  • UI-Ressourcen sind auf 2 MiB begrenzt, werden hinter einem Doppel-Iframe-Proxy auf einem eigenen äußeren Origin platziert, in einen undurchsichtigen inneren App-Origin geladen und durch eine aus den Ressourcenmetadaten abgeleitete CSP eingeschränkt.
  • Ausschließlich für Apps bestimmte Tools (_meta.ui.visibility: ["app"]) bleiben aus den Toollisten des Modells ausgeschlossen. Apps können nur für Apps sichtbare Tools auf ihrem zugehörigen Server aufrufen, die außerdem die wirksame OpenClaw-Toolrichtlinie für den Lauf erfüllen, der die Ansicht erstellt hat.
  • An den Origin gebundene App-Berechtigungen wie Kamera, Mikrofon und Geolokalisierung werden nicht erteilt, solange innere App-Dokumente undurchsichtige Origins zur App-übergreifenden Isolation verwenden.
  • App-HTML, vollständige Toolargumente und unverarbeitete Ergebnisse verbleiben in einem begrenzten, zehn Minuten gültigen In-Memory-Ansichts-Lease und werden weder auf den Datenträger geschrieben noch in die Vorschaumetadaten des Transkripts kopiert. Das Transkript speichert nur einen begrenzten Server-/Tool-/Ressourcendeskriptor, der an die ursprüngliche Toolaufruf-ID gebunden ist. Nach einem Gateway-Neustart kann die Control UI diesen Deskriptor anhand des Transkripts der authentifizierten Sitzung überprüfen und die Ressource ui:// erneut abrufen; wiederhergestellte Ansichten sind schreibgeschützt, bis ein neuer Lauf aktuelle Toolberechtigungen festlegt.
  • In Kanalunterhaltungen fügt die letzte erfolgreiche App-Ansicht eines Durchgangs der abschließenden Assistentenantwort eine Aktion im Stil von App öffnen hinzu. Telegram-Direktnachrichten verwenden eine native Mini-App-Schaltfläche; Slack und Discord stellen dieselbe portable Aktion als Link dar. Andere Kanäle behalten den ursprünglichen Antworttext bei und hängen einen verständlichen HTTPS-Link an.
  • Kanal-Startlinks sind nur verfügbar, wenn die Tailscale-Bereitstellung des Gateways einen veröffentlichten HTTPS-Origin vorbereitet hat. gateway.tailscale.mode: "serve" ist nur aus dem Tailnet erreichbar; "funnel" ist aus dem öffentlichen Internet erreichbar. Ein extern verwalteter Funnel, der durch gateway.tailscale.preserveFunnel beibehalten wird, gilt ebenfalls als über das Internet erreichbar. Siehe Tailscale.
  • Starttickets sind undurchsichtig, werden ausschließlich beim Erstellen der abschließenden Kanalantwort ausgestellt und laufen nach höchstens zwei Minuten oder beim Ablauf des zugrunde liegenden Ansichts-Lease ab, je nachdem, was zuerst eintritt. Die URL enthält keine Gateway-Bearer-Anmeldedaten, Sitzungsschlüssel, Ansichtsmetadaten, App-HTML, Tooleingaben oder Toolergebnisse.
  • Wenn kein veröffentlichter Origin oder keine Ticketkapazität verfügbar ist, die Ansicht oder das Ticket abgelaufen ist oder der Transport keine nativen Steuerelemente darstellen kann, bleibt der ursprüngliche Assistententext verfügbar. Die Control UI behält ihre vorhandene eingebettete App-Zeichenfläche bei und erhält keine doppelte Startaktion.
  • openclaw security audit warnt, solange die Bridge aktiviert ist. Deaktivieren Sie sie mit openclaw config set mcp.apps.enabled false --strict-json, wenn sie nicht benötigt wird.

Aktuelle Einschränkungen

Diese Seite dokumentiert die Bridge in ihrem derzeit ausgelieferten Zustand. Aktuelle Einschränkungen:
  • die Unterhaltungserkennung hängt von vorhandenen Metadaten der Gateway-Sitzungsroute ab
  • kein generisches Push-Protokoll über den Claude-spezifischen Adapter hinaus
  • noch keine Tools zum Bearbeiten von Nachrichten oder Hinzufügen von Reaktionen
  • der HTTP-/SSE-/Streamable-HTTP-Transport verbindet sich mit einem einzelnen entfernten Server; noch kein gebündelter Upstream
  • permissions_list_open enthält nur Genehmigungen, die beobachtet wurden, während die Bridge verbunden war

Verwandte Themen