I Built the Universal Translator for MCP, A2A, and ACP Agents — So They Can Finally Collaborate (Docker + Live Swagger Demo)
If you’ve tried building a real multi-agent system in 2026, you already know the pain.
Anthropic’s MCP agent wants to hand off a task.
Google’s A2A agent expects a completely different envelope.
IBM’s ACP agent uses yet another schema.
Result? You spend weeks writing custom adapters instead of actually building agents.
I got tired of it. So in a few weeks of vibe-coding I shipped a middleware bridge that translates protocols and resolves semantic differences automatically.
It’s open source, one-command to run, and already has a live Swagger UI. Here’s how it works and why it might save you months of pain.
The 2026 Agent Protocol Wars (yes, it’s that bad)
Right now the ecosystem is exploding:
- MCP (Anthropic) — great for model context and tools
- A2A (Google) — focused on direct agent-to-agent handoffs with Agent Cards
- ACP (IBM) — structured coordination in shared environments
They’re all excellent… in isolation.
Cross-protocol? Manual JSON mapping hell.
This is the exact fragmentation everyone is complaining about on Reddit, HN, and Medium right now.
The Solution: Engram Translator Middleware
One lightweight FastAPI service that sits in the middle and does two things:
- Protocol Translation — converts envelopes between MCP ↔ A2A ↔ ACP
-
Semantic Mapping — uses OWL ontologies + PyDatalog + JSON Schema + ML fallback to fix field mismatches (e.g.
user_info.name→profile.fullname)
Plus built-in:
- Agent Registry & Discovery (with compatibility scores)
- Async orchestration + retries
- JWT auth layer
Full architecture diagram:
``mermaid
flowchart LR
A[Source Agent\nProtocol: MCP] -->|Task Request| B(Translator\nMiddleware)
B -->|Protocol & Semantic Translation| C[Target Agent\nProtocol: A2A]`
Try It in 60 Seconds
`bash docker compose up --build`
That’s it.
Swagger UI lives at http://localhost:8000/docs
You can immediately:
- Register agents
- Discover compatible collaborators
- Translate messages across protocols
Real example (from the README):
`bash
# Register an A2A agent
curl -X POST http://localhost:8000/api/v1/register \
-H "Content-Type: application/json" \
-d '{"agent_id":"agent-a","endpoint_url":"http://agent-a:8080","supported_protocols":["a2a"],"semantic_tags":["scheduling"]}'
# Send a meeting request from an MCP agent to that A2A agent
curl -X POST http://localhost:8000/api/v1/translate \
-H "Authorization: Bearer <your-jwt>" \
-d '{"source_agent":"agent-b","target_agent":"agent-a","payload":{"intent":"schedule_meeting"}}'`
The middleware handles the translation and returns the properly mapped payload.
Why This Actually Works
in ProductionSemantic engine falls back to ML when rules aren’t enough
Registry gives you real-time discovery (compatibility score 0.95 = green light)
Redis + Neon backend for scale
Full tests + GitHub Actions already running
It’s the missing “TCP/IP layer” for agents that everyone keeps asking for.The Bigger VisionThis is the core piece of the open-source Engram agent-economy stack I’m building.
The goal: any agent, any protocol, seamless collaboration.
Try It & Star the Project
Full landing page (more details + vision):
https://www.useengram.com
GitHub repo(star it ):
https://github.com/kwstx/engram_translator
Try the Docker demo and let me know:Does the semantic mapping catch your use-case?
What protocols are you fighting with right now?
I read every comment and I’m actively shipping fixes.
If this saves you even one day of integration hell, smash that — it helps the repo reach more builders who are stuck in the same spot.Happy to accept PRs on custom ontology rules or new protocol support too.Let’s finally make agents talk to each other.#ai-agents
Top comments (0)