mcp-acp-bridge

Un servidor ACP que actúa como proxy para cualquier agente de codificación que hable MCP.

El puente aloja un servidor MCP para el agente y habla ACP con un editor o cliente. Debido a que cada llamada de herramienta que realiza el agente pasa a través de él, el puente puede retener cada una y pedir primero la aprobación al cliente, convirtiendo las llamadas de herramienta en auténticas solicitudes de permiso en cualquier interfaz de usuario que las gestione.

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

Estado: la mitad MCP funciona. La mitad ACP aún no existe.

La interceptación de herramientas y el control de permisos están implementados y verificados de extremo a extremo contra Claude Code como cliente MCP en vivo: una llamada es interceptada, retenida, permitida o denegada, y una denegación regresa al agente como texto legible. Lo que falta es el servidor ACP que convierte esas retenciones en session/request_permission para un cliente real, y el supervisor del agente. Ver docs/design.md.

Try it

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 necesita la CLI claude en PATH y autenticada. Proporciona a Claude Code un endpoint MCP por sesión, le pide que llame a una herramienta y muestra la interceptación:

[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

Why

Algunos agentes de codificación no emiten salida estructurada. La CLI Antigravity de Google (agy) es el caso motivador: no tiene modo ACP (solicitud upstream), y en modo headless imprime texto plano y deniega automáticamente cualquier permiso que no pueda solicitar. Por lo tanto, manejarlo desde una GUI significa raspar una TUI o renunciar a las aprobaciones.

Este puente toma un tercer camino. Ignora lo que el agente dice e intercepta lo que el agente hace: las llamadas de herramienta MCP ya están estructuradas, ya son observables y –fundamentalmente– ya son interceptables. Un servidor MCP no es un oyente, es una puerta.

Nada en este enfoque es específico de un agente. Cualquier agente que pueda ser dirigido a un servidor MCP funciona.

What it does and does not see

MCP es un canal de herramientas, no un canal de salida del agente.

Las herramientas integradas de archivo y shell de un agente no atraviesan MCP, por lo que no generan ningún tool_call. Eso es una brecha de visibilidad, no de corrección: los clientes que guardan el estado del espacio de trabajo (T3 Code lo diferencia en los límites de turno) aún registran lo que cambió. Lo que se pierde es el progreso en vivo por acción, no el registro.

Enrutar las herramientas integradas a través del puente como herramientas MCP cierra esa brecha y mejora el modelo de seguridad de permisos permanentes a revisión por acción. Es un endurecimiento planificado, no un requisito previo.

MCP revision support

Se admiten tanto la revisión actual como la entrante, porque el puente nunca depende del estado del transporte MCP:

Las sesiones ACP se correlacionan mediante una URL de endpoint con ámbito de ruta, una por ejecución de agente, por lo que ambas revisiones se comportan de manera idéntica. Ver docs/design.md.

License

MIT. Ver LICENSE.