Local MCP mailbox shared by the Codex and Antigravity desktop clients. Each MCP client starts its own stdio instance. Instances communicate through the same append-only JSONL mailbox, so no background service or credentials are required. The bridge is intentionally local-only and exposes only message transport/status tools; it does not execute commands from messages.
Four tools with complete JSON schemas and reasonable descriptions. Naming follows verb_noun pattern (bridge_send, bridge_receive, bridge_status, bridge_ping). Schemas include type definitions and constraints (e.g., limit 1-100, message max 16,384 bytes). However, descriptions are brief (34-72 chars), parameter descriptions lack depth, and error handling is minimal. No output schema documentation. Tool composition is sound (each does one thing), but descriptions don't explain WHEN to use each tool or dependencies between them.
Confirm that the local Codex–Antigravity bridge is reachable.
Read messages addressed to this desktop agent from the local shared mailbox.
Send a bounded text message to Codex, Antigravity, or both through the local shared mailbox.
Report local bridge connectivity and mailbox status without reading message bodies.
Descriptions are too brief (34-72 chars vs. baseline 194 chars). LLMs cannot determine when to select bridge_ping vs bridge_status, or bridge_receive vs bridge_send. Add context: WHAT does it do, WHEN to use it, WHAT it returns.
Parameter descriptions lack actionable detail. 'Optional message id or ISO timestamp cursor' does not explain the cursor semantics or how to use it. 'Recipient agent id, or all' does not explain valid format or how agent IDs are resolved.
No output schema documentation. Callers must infer response structure from code. bridge_send returns a record JSON; bridge_receive returns {agent, messages, next}; bridge_status returns {server, version, agent, ...}. Document these formally.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Error responses are generic text ('message is required', 'target must be all or a simple agent identifier'). No guidance on recovery. Should include: what went wrong, why, and what to do next (e.g., 'Invalid target: must match [a-zA-Z0-9._-]{1,64}').
bridge_ping and bridge_status are near-duplicates. bridge_ping confirms reachability; bridge_status reports connectivity AND mailbox state. Unclear when to call which. Merge or clarify distinct responsibilities.