mcp-acp-bridge

Ein ACP-Server, der als Frontend für jeden MCP-sprechenden Coding-Agenten dient.

Die Bridge hostet einen MCP-Server für den Agenten und spricht ACP mit einem Editor oder Client. Da jeder Tool-Aufruf des Agenten durch sie hindurchgeht, kann die Bridge jeden einzelnen anhalten und zuerst den Client um Genehmigung bitten – und so Tool-Aufrufe in echte Berechtigungsabfragen in der jeweiligen Benutzeroberfläche verwandeln.

client (T3 Code, Zed, …) ──ACP──► bridge ──MCP──► agent (agy, claude, codex, …)
                                    │
                                    └─ spawns and supervises the agent process

Status: Die MCP-Hälfte funktioniert. Die ACP-Hälfte existiert noch nicht.

Tool-Interception und Berechtigungssteuerung sind implementiert und End-to-End gegen Claude Code als live MCP-Client verifiziert – ein Aufruf wird abgefangen, angehalten, erlaubt oder verweigert, und eine Verweigerung kommt als lesbarer Text zum Agenten zurück. Was fehlt, ist der ACP-Server, der diese Anhaltevorgänge in session/request_permission für einen echten Client umwandelt, sowie der Agent Supervisor. Siehe docs/design.md.

Ausprobieren

npm install
npm test              # unit tests, no agent required
npm run test:live     # drives the real `claude` CLI against the gateway
npm run test:live deny

test:live benötigt die claude CLI im PATH und authentifiziert. Es übergibt Claude Code einen pro-Sitzung MCP-Endpunkt, bittet es, ein Tool aufzurufen, und zeigt die Interception an:

[tool] requested magic_word
[gate] DENY magic_word {}
[tool] denied magic_word (denied by test policy)
[claude] said: The tool call was denied. The error returned was exactly:
         `Error: permission denied: denied by test policy`

Related MCP server: agentic-governance-gateway

Warum

Manche Coding-Agenten geben keine strukturierte Ausgabe aus. Googles Antigravity CLI (agy) ist der motivierende Fall: Es hat keinen ACP-Modus (Upstream-Anfrage), und im Headless-Modus gibt es Klartext aus und lehnt automatisch jede Berechtigung ab, für die es nicht nachfragen kann. Es von einer GUI aus zu steuern bedeutet daher entweder, ein TUI zu scrapen oder auf Genehmigungen zu verzichten.

Diese Bridge geht einen dritten Weg. Sie ignoriert, was der Agent sagt, und fängt ab, was der Agent tut: MCP-Tool-Aufrufe sind bereits strukturiert, bereits beobachtbar und – entscheidend – bereits abfangbar. Ein MCP-Server ist kein Zuhörer, sondern ein Tor.

Nichts an diesem Ansatz ist agentenspezifisch. Jeder Agent, der auf einen MCP-Server ausgerichtet werden kann, funktioniert.

Was es sieht und nicht sieht

MCP ist ein Tool-Kanal, kein Agenten-Ausgabekanal.

Die eingebauten Datei- und Shell-Tools eines Agenten durchlaufen MCP nicht, daher erzeugen sie keinen tool_call. Das ist eine Sichtbarkeitslücke, keine Korrektheitslücke – Clients, die den Arbeitsbereich sichern (T3 Code diffed ihn an Turn-Grenzen), zeichnen dennoch auf, was sich geändert hat. Verloren geht der Live-Fortschritt pro Aktion, nicht die Aufzeichnung.

Das Routing eingebauter Tools durch die Bridge als MCP-Tools schließt diese Lücke und verbessert das Sicherheitsmodell von dauerhaften Berechtigungen hin zu einer Überprüfung pro Aktion. Es ist eine geplante Härtung, keine Voraussetzung.

MCP-Revisionsunterstützung

Sowohl die aktuelle als auch die kommende Revision werden unterstützt, da die Bridge niemals etwas vom MCP-Transportzustand abhängig macht:

ACP-Sitzungen werden durch eine pfadbezogene Endpunkt-URL korreliert, eine pro Agentenlauf, sodass sich beide Revisionen identisch verhalten. Siehe docs/design.md.

Lizenz

MIT. Siehe LICENSE.