EVEX Agent Messaging Gateway

Transporte MCP neutral respecto al proveedor para operaciones de conversación de Parent Main, Child Main y Role Child. Los agentes llaman a este MCP; no llaman directamente a la Conversation API de OpenHands.

Herramientas

• create_child: valida la Misión estructurada completa y el checkout de Git determinista y limpio, vincula la identidad del Child y la capacidad de callback, y luego crea una Conversación determinista. El proveedor ejecuta un turno de admisión sin herramientas, restaura y revalida la rama/head exacta después del arranque de ACP, y solo entonces admite herramientas y entrega la Misión. No se produce ninguna llamada a la Conversation API cuando falta la autoridad de checkout o no coincide. Los roles de origen reciben solo mensajería; solo las Misiones explícitas de QA/reparación pueden solicitar capabilities: ["runtime_environment"].

• send_to_parent: entrega un RESULT/NEEDS_INPUT estructurado al Main propietario de la capacidad.

• request_user_decision: entrega una pregunta de estilo A/B/C al Main propietario.

• cancel_mission / resume_mission: detiene o reanuda la tarea exacta del Child.

• publish_navigation_links: publica enlaces informativos de Issue/Main/Child/PR al Main propietario.

Las capacidades son referencias compactas opacas evx1_ HMAC-SHA256. Vinculan el Main propietario, el Child, la clave de tarea, el rol, la acción permitida y la expiración. El servidor posee la credencial de OpenHands; nunca aparece en la entrada de herramientas, en la salida de herramientas ni en las variables de entorno del Child. No hay estado persistente: los llamadores proporcionan una clave de mensaje estable y el Main deduplica las repeticiones semánticas.

Cada Child creado recibe un hook nativo asíncrono de Stop. El hook llama al endpoint privado /completion-hook con su referencia de ámbito; la puerta de enlace espera el estado nativo terminal y envía un RECOVERY_WAKE estable que contiene la respuesta acotada del asistente terminal al Main propietario. Este es el respaldo neutral respecto al proveedor cuando un modelo termina sin llamar a send_to_parent. Los hooks repetidos reutilizan la misma clave de mensaje semántica y no requieren una base de datos, sondeador, herramienta de lectura ni almacén de recibos.

El Event Gateway/host de confianza acuña la capacidad Main de corta duración con main_capability_token(...) y la inyecta en la Misión Main. El MCP no expone una herramienta de acuñación de capacidades a los agentes.

El Parent crea o recupera solo el mirror bare persistente en /home/openhands/workspace/mirrors/<owner>--<repository>.git. create_child deriva /home/openhands/workspace/delivery/child-<child UUID>, crea el worktree de la rama exacta cuando no existe, y valida el repositorio, el origin, la rama, el head y la limpieza antes de tocar la Conversation API. Nunca clona/hace fetch remoto, elimina, resetea ni reutiliza un worktree existente.

Related MCP server: handoff-mcp-server

Ejecución

El servidor usa el framing stdio de MCP (cabeceras Content-Length):

export EVEX_MESSAGING_SECRET='long-random-secret'
export OPENHANDS_URL='http://openhands:8000'
export OPENHANDS_API_KEY='server-only-key'
export OPENHANDS_PUBLIC_URL='http://openhands.example/canvas'
PYTHONPATH=src python3 -m evex_agent_messaging

Solo el adaptador lee las variables de OpenHands. Se puede inyectar un proveedor falso en pruebas o mediante un host que incruste el servicio, de modo que las habilidades y las Misiones permanecen neutrales respecto al entorno de ejecución.

Validación

python3 -m unittest discover -s tests -p 'test_*.py' -q