MCP-Server verbinden

MCP (Model Context Protocol) ist der Standardweg, um externe Tools an einen Agenten anzuschließen — GitHub, Dateisysteme, Notion, Datenbanken und hunderte weitere Server sprechen es. Chimera hat einen erstklassigen MCP-Client: Die Tools jedes Servers werden zu gewöhnlichen Chimera-Tools, die in derselben Registry wie die eingebauten sitzen, kontrolliert von denselben Allowlist-/Kernel-/Ledger-Schichten.

Remote Streamable HTTP

Für einen MCP-Endpunkt, der Streamable HTTP spricht, konfigurieren Sie url statt command. Die CLI akzeptiert chimera mcp add NAME --url https://host.example/mcp; authentifizieren Sie sich mit --token-env ENVIRONMENT_VARIABLE, um einen Bearer-Token zur Laufzeit aufzulösen, ohne seinen Wert in mcp.json zu speichern.

Für einen lokalen stdio-Server legt chimera mcp add NAME --command ... --cwd DIRECTORY sein Arbeitsverzeichnis fest (relative Pfade werden vom Chimera-Arbeitsbereich aus aufgelöst und müssen bereits existieren). --catalog-timeout SECONDS legt das unabhängige Limit für das Abrufen des Werkzeugkatalogs fest; --connect-timeout begrenzt nur den Verbindungsaufbau. Argumente und Werte von --env KEY=VALUE können {env:NAME}-Referenzen enthalten, die zum Verbindungszeitpunkt aus der Prozessumgebung von Chimera aufgelöst werden. Fehlt eine Variable, schlägt die Verbindung fehl; die aufgelösten Werte werden weder in mcp.json zurückgeschrieben noch von der API zurückgegeben. Um einen Server anzuhalten, ohne seine Konfiguration oder sein genehmigtes Manifest zu löschen, verwenden Sie chimera mcp disable NAME; mit chimera mcp enable NAME wird er wieder aktiviert. Deaktivierte Server bleiben in der Konfiguration sichtbar, werden aber weder verbunden noch eingebunden.

Die meisten gehosteten MCP-Server (Notion, Linear, Atlassian, Supabase…) melden sich mit OAuth an. Fügen Sie einen per URL hinzu (chimera mcp add notion --url https://mcp.notion.com/mcp) und melden Sie sich mit chimera mcp login notion in einem Terminal an oder mit Verbinden auf dem MCP-Bildschirm der App. Chimera folgt der MCP-Autorisierungsspezifikation (Revision 2025-11-25): Es ermittelt den Autorisierungsserver aus den Protected-Resource-Metadaten des Servers (RFC 9728, RFC 8414 / OpenID-Discovery), lehnt einen anderen Aussteller als den vom Server angekündigten ab, registriert sich dynamisch (RFC 7591), wenn keine oauth_client_id konfiguriert ist, und führt den Authorization-Code-Flow mit PKCE S256 und dem resource-Indikator (RFC 8707) über eine Loopback-Weiterleitung auf 127.0.0.1 mit zufälligem Port aus (RFC 8252). Tokens werden bei Ablauf erneuert. Trennen (oder chimera mcp logout) widerruft sie, wo der Server das unterstützt. Ein Server mit vorregistriertem Client funktioniert weiter über oauth_authorization_url, oauth_token_url und oauth_client_id.

Tokens und der registrierte Client liegen im Anmeldedaten-Tresor des Betriebssystems (das optionale Extra secrets) oder, wo es keinen Tresor gibt (ein Container, ein VPS), in <home>/mcp_oauth/ mit Modus 0600. Nie in mcp.json, nie in einem Log, nie in einer API-Antwort; die Lesewerkzeuge und die Shell des Agenten bleiben aus diesem Ordner heraus. Ein Browser öffnet sich nur auf Aktion des Eigentümers: chimera mcp login verweigert ohne interaktives Terminal, und Verbinden verlangt das Fenster der App selbst. Alles Unbeaufsichtigte (der Pool, serve, die Bots, Cron, der Test des Bildschirms) nutzt die gespeicherte Anmeldung oder schlägt mit dem Hinweis fehl, in der App zu verbinden. Ein Anmeldedatum wird nur über https gesendet oder über einfaches http an Loopback.

Remote-Server durchlaufen dieselbe konfigurierte MCP-Tool-Schnittstelle, denselben Registry-Namespace, denselben langlebigen Pool, denselben Probe-Befehl, dieselbe Fehlerbehandlung und denselben Beobachtungszaun wie stdio-Server. Behandeln Sie die Metadaten und Ergebnisse von Remote-Tools als nicht vertrauenswürdigen Serverinhalt.

Das Client-Extra installieren

Der MCP-Client liegt hinter einem optionalen Extra, damit der Kern schlank bleibt:

uv sync --extra mcp

Die meisten Server sind Node-Pakete, daher wird auch npx benötigt (kommt mit Node.js).

60-Sekunden-Smoke-Test (ohne Zugangsdaten)

Der Referenz-Dateisystemserver braucht keine Token — er stellt nur Lese-/Schreib-Tools über ein von dir gewähltes Verzeichnis bereit:

from chimera.integrations import connect_stdio
from chimera.tools import default_registry

connector = connect_stdio(
    "fs",
    "npx", ["-y", "@modelcontextprotocol/server-filesystem", "./sandbox_dir"],
    name_prefix="fs_",   # avoid clashes with built-in tool names
)

registry = default_registry()
for tool in connector.tools():
    registry.register(tool)

print(registry.names())  # built-ins + fs_read_file, fs_write_file, fs_list_directory...

Diese Registry an einen Agent übergeben (oder examples/mcp_github.py für die vollständige Loop ansehen), und das Modell kann jetzt die Tools des Servers wie jedes andere aufrufen.

Ein echter Server: GitHub

import os
from chimera.integrations import connect_stdio

connector = connect_stdio(
    "github",
    "npx", ["-y", "@modelcontextprotocol/server-github"],
    env={"GITHUB_PERSONAL_ACCESS_TOKEN": os.environ["GITHUB_PERSONAL_ACCESS_TOKEN"]},
    name_prefix="gh_",
)

Das ist die ganze Integration: ~26 GitHub-Tools (Repos durchsuchen, Dateien lesen, Issues auflisten, PRs erstellen, …) erscheinen in der Registry. Lauffähige End-to-End-Version: examples/mcp_github.py.

Wie es zu den Sicherheitsschichten passt

MCP-Tools sind gewöhnliche Tool-Objekte, sodass sich alles zusammensetzt:

Allowlist pro Sitzung — restrict_registry(registry, allow=["gh_search_repositories", ...]) gewährt nur die MCP-Tools, die dieser Lauf braucht; nicht gewährte erreichen das Modell nie.
Governance-Kernel — govern_registry(...) kontrolliert MCP-Aufrufe mit allow/warn/ review/block, genau wie jeden Shell-Befehl.
Taint-Ledger — mit ledger_registry(...) umhüllen, und MCP-Fetches werden erfasst; zu beachten ist, dass heute nur die in FETCH_TOOLS genannten Tools automatisch klassifiziert werden, MCP-Inhalte also als nicht vertrauenswürdig behandelt und bevorzugt mit der Semantik --taint --guard ausgeführt werden sollten, wenn der Server externe Daten zieht.
Server-instructions — der Text, den ein Server bei initialize zurückgibt, wird verworfen, und zwar bewusst: Er ist nicht vertrauenswürdiger Server-Text, und nichts kennzeichnet ihn als Daten, wie es ein umzäunter Abruf tut. Der Preis ist, dass die Nutzungshinweise eines Servers das Modell nie erreichen; ein Host, der sie weitergibt, sollte sich aber auch nicht darauf verlassen (arXiv 2608.08467: mit verfügbarem Suchwerkzeug fielen 9 von 24 Modellen bei Nachschlagefragen in Server-Anweisungen unter 15 %). Sie als umzäunte Daten unter Taint weiterzugeben ist offen, nicht erledigt. Das Verwerfen ist keine Grenze gegen vom Server geschriebenen Text: Werkzeugnamen und -beschreibungen desselben Servers erreichen das Modell so, wie der Server sie schrieb, ohne Zaun; ein Server, den du anbindest, ist ein Server, dessen Worte das Modell liest.
Manifest-Pinning — beim ersten Einbinden eines Servers werden Namen, Beschreibungen und Input-Schemas seiner Tools in mcp_pins.json neben mcp.json gespeichert. Listet ein späteres Einbinden irgendetwas anders, wird der Server zurückgehalten: Der gemeinsame MCP-Pool bindet ihn für Aufrufer, die diesen Pool nutzen, nicht ein, bis Sie die Änderung freigeben, mit altem und neuem Text nebeneinander, über chimera mcp approve NAME oder den MCP-Bildschirm. Das Manifest-Gate des Pools ist in chimera/integrations/mcp_pool.py implementiert. chimera mcp list nennt zurückgehaltene Server. Die eingebundenen Tools sind genau die geprüfte Liste, sodass ein Server der Prüfung nicht einen Text und dem Modell einen anderen liefern kann. Hinzufügen oder Entfernen des Servers über chimera mcp add/remove oder die App vergisst seinen Pin (das nächste Einbinden ist wieder der Erstkontakt). Pinning ist Vertrauen beim ersten Gebrauch: Es erkennt eine Beschreibung, die sich ändert, nicht eine, die von Anfang an feindselig war. Nicht abgedeckt: die Python-API oben. connect_stdio bindet ein, was der Server listet, und ebenso autoload_into_registry, sofern Sie ihm nicht mcp_path übergeben, die Datei, deren Pins es prüfen soll.
Auswahl-Signale — chimera mcp test und der MCP-Bildschirm markieren Tools mit Formulierungen, die steuern wollen, welches Tool das Modell wählt („always use this tool", „do not use other tools", „ignore previous instructions", <IMPORTANT>), gelesen in der Beschreibung und in jeder Parameterbeschreibung. Nur eine Anmerkung: Sie verweigert nichts, und wie oft sie bei ehrlichen Servern anschlägt, wurde nicht gemessen.

Chimera als MCP-Server

Der obige Client lässt Chimera andere Tools aufrufen. Der umgekehrte Weg funktioniert auch: Chimera als MCP-Server laufen lassen, sodass jeder MCP-Client — Claude Desktop, eine IDE, ein anderer Agent — die gesamte Engine als drei Tools aufrufen kann.

uv sync --extra mcp
chimera serve --mcp        # speaks MCP over stdio

Es stellt bereit:

Tool	Was es tut
`chimera_solve`	Löst eine Aufgabe autonom mit Plan + verify-or-revert; gibt die Antwort zurück.
`chimera_fuse`	Beantwortet einen Prompt über die LLM-Fusion-Engine (Panel → Judge → Synthesizer).
`chimera_memory_search`	Durchsucht Chimeras Langzeitgedächtnis und gibt die wichtigsten Fakten zurück.

Einen MCP-Client als Stdio-Server darauf verweisen. Für Claude Desktop zur Konfiguration hinzufügen:

{
  "mcpServers": {
    "chimera": { "command": "chimera", "args": ["serve", "--mcp"] }
  }
}

--mcp braucht einen Provider-Key für chimera_solve/chimera_fuse (die Speichersuche funktioniert ohne). --fuse hinzufügen, um die tiefen Turns des Solvers über Fusion zu leiten, --no-memory, um den Recall zu überspringen. Da Stdio die Leitung ist, gehen alle Logs an stderr — stdout trägt nur das Protokoll.

Claude die Desktop-App bedienen lassen

chimera serve --mcp baut einen eigenen Agenten. chimera mcp desktop baut nichts: Es ist eine Fernbedienung für die Desktop-App, die du schon offen hast, also sieht Claude dieselben Unterhaltungen, Läufe und Freigaben wie du, und was es startet, läuft unter der Governance der App, auf ihren Bildschirmen.

Öffne in der App Einstellungen → Claude und schalte Claude diese App bedienen lassen ein.
Registriere den Server in Claude Code (oder trage denselben Befehl in die Config von Claude Desktop ein):
```
claude mcp add chimera-desktop -- chimera mcp desktop
```

Mit dem ersten Schalter kann Claude Unterhaltungen lesen und starten (desktop_send), ebenso Läufe, Batches, Boards und Cron-Jobs, das Gedächtnis durchsuchen und bearbeiten sowie Dateien und den Git-Stand lesen. Ein Lauf, den es startet, trägt die Haltung, die du konfiguriert hast, und eine Anfrage, die sie ausweiten will — ein verify-Befehl, Ausführung auf dem Host, ein anderer Agent, Auto-Freigabe — wird abgelehnt. Freigaben bleiben bei dir: desktop_approvals listet sie nur auf. Hält ein Zug bei einer an, antwortet desktop_send sofort, dass er auf dich wartet, und der Zug läuft in der App weiter; desktop_job meldet, wie er endet.

Der zweite Schalter, Volle Kontrolle, fügt desktop_approve (Freigaben und Schritte mit Schranke beantworten) und desktop_settings (Einstellungen und die Identität des Agenten bearbeiten) hinzu. Damit kann Claude Aktionen ohne dich freigeben — und eine Seite oder Nachricht mit Prompt-Injection, die der Agent liest, könnte es dazu bringen. Diese beiden Tools werden gar nicht gelistet, solange er aus ist, und die App lehnt sie ab, falls sie trotzdem aufgerufen werden.

Manche Entscheidungen bleiben deine, egal welcher Schalter an ist. Welches Modell antwortet — jede Modelleinstellung, die Fallback-Kette, Panel, Richter und Synthesizer der Fusion, der Kostenmodus, die Kaskade und geprüfte Antworten — und ob die App geplante Jobs ausführt, kann Claude nur vorschlagen: Es wird nichts geschrieben, und die App zeigt dir eine Karte mit dem aktuellen und dem vorgeschlagenen Wert jeder Einstellung, die du dort freigibst oder ablehnst. Claude kann diese Karte auf keinem Weg beantworten; hat sich die Einstellung vor deiner Freigabe geändert, wird nichts übernommen. Einem Ordner Befehle erlauben, einen Befehl im Runner ausführen, einen Messaging-Bot starten und einen Agenten mit seinen Tool-Rechten speichern lehnt die Brücke ganz ab: Das machst du in der App.

Und ein Lauf, den Claude startet, läuft unter beiden Schaltern mit den Modellen, die du eingestellt hast, und reicht nicht weiter als deine eingestellte Haltung. Eine Anfrage, die ein Modell, einen Rollenplan, ein Profil, ein Fusions-Panel oder einen anderen Agenten nennt, wird abgelehnt; ebenso eine weitere Haltung — mehr Reichweite, lockerere Freigaben, Ausführung auf dem Host oder ein verify-Befehl, wo du keine Shell erlaubt hast, oder automatische Freigabe. Einen Lauf um weniger zu bitten (nur lesen, oder immer fragen) ist erlaubt.

Was kein Schalter erlaubt: einen API-Schlüssel, ein Token oder einen Webhook lesen oder schreiben. Einstellungsänderungen lehnen Namen von Zugangsdaten ab, die Routen mit Schlüsseln oder Freigabelinks sind nicht erreichbar, Dateien mit Zugangsdaten (.env, private Schlüssel) lassen sich weder lesen noch schreiben noch durchsuchen, und jedes Ergebnis wird von Werten der Zugangsdaten bereinigt. Auch ein Workspace auf dem Datenordner der App oder auf einem Ordner, der ihn enthält (etwa deinem Home-Verzeichnis), wird abgelehnt: Dort liegen die Antworten auf Freigaben, und eine dort geschriebene Datei würde eine beantworten.

Wie die Verbindung entsteht: Solange der Schalter an ist, schreibt die App ~/.chimera/desktop-bridge.json (die URL ihrer Loopback-API und ein zufälliges Token; unter POSIX nur für dich lesbar, unter Windows in deinem Profil). Den Schalter auszuschalten oder die App zu schließen löscht die Datei und macht das Token ungültig. Bei geschlossener App antwortet jedes Tool „Chimera desktop is not running, or 'Allow Claude to operate this app' is off in Settings.“ Claude listet die Tools beim Verbinden; nach dem Ein- oder Ausschalten von Volle Kontrolle den Server neu verbinden (/mcp in Claude Code), um die neue Liste zu sehen.

A2A sprechen (Agent → Agent)

MCP verbindet Agenten mit Tools; A2A (Agent2Agent, Linux Foundation) verbindet Agenten miteinander — es ist nativ in LangGraph, CrewAI und AutoGen. Chimera spricht es ebenfalls, sodass ein LangGraph-/CrewAI-Orchestrator eine Aufgabe an Chimera delegieren und ein abgeschlossenes Ergebnis zurückbekommen kann.

chimera a2a-card                       # print the Agent Card JSON
chimera serve --a2a                    # HTTP gateway + A2A endpoint

serve --a2a fügt dem HTTP-Server zwei Routen hinzu:

Route	Zweck
`GET /.well-known/agent.json`	Die Agent Card — Identität + beworbene Skills (solve, fuse).
`POST /a2a`	JSON-RPC-2.0-Task-Lebenszyklus: `message/send`, `message/stream`, `tasks/get`, `tasks/cancel`.

Ein Client sendet message/send mit einem Textteil; Chimera führt den autonomen Agenten aus und gibt einen completed- (oder failed-)Task mit der Antwort als Agentennachricht zurück. Oder er sendet message/stream und erhält einen Server-Sent-Events-Stream: zuerst den Task im Zustand working, dann den Task completed/failed, sobald der Lauf beendet ist — sodass ein Orchestrator Fortschritt sieht, ohne zu pollen. Die Agent Card bewirbt capabilities.streaming: true.

Umfang, ehrlich gesagt: Der Stream sendet derzeit zwei Events (working → final), keine Token-Deltas pro Schritt, und Push-Benachrichtigungen sind nicht implementiert. Das ist ein konformer, poll-freier Stream — genug, um ein erstklassiger, streambarer Knoten in einer LangGraph-/CrewAI-App zu sein.

Fehlerbehebung

TimeoutError: MCP server ... did not become ready — der Befehl ist nicht gestartet. Dieselbe npx ...-Zeile manuell in einem Terminal ausführen, um den Fehler zu sehen (fehlender Token, fehlendes Node, langsamer Paket-Download beim ersten Lauf — connect_timeout erhöhen).
ModuleNotFoundError: mcp — das Extra installieren: uv sync --extra mcp.
Namenskollisionen bei Tools — immer einen name_prefix übergeben.
Die Sitzung führt den Server für die Lebensdauer deines Skripts als Subprozess aus; die close()-Methode der connector-Session aufrufen (oder den Prozess einfach beenden lassen), um ihn abzubauen.

Diese Seite auf GitHub bearbeiten