Since late 2025, AI agent standards have been arriving in a cluster. Anthropic donated MCP to the Linux Foundation, Google announced A2A, and OpenAI published the Open Responses spec. That's great news for the ecosystem — but it's also confusing as hell. What does each one do? Are they competing? Can they coexist?
My first reaction was "another protocol war." Then I built a few MCP servers myself, read through the A2A spec, and my view changed. These three protocols aren't competing — they occupy different layers. The confusion comes from the fact that all three sound like "agent communication standards" when you read the names.
In this post I'll break down each protocol and give my honest take on when to use what.
MCP: Giving Agents Hands
MCP (Model Context Protocol) was published by Anthropic in late 2024 and donated to the Linux Foundation's Agentic AI Initiative (AAIF) in December 2025. Its core purpose is singular: standardize how AI models access external tools and data.
The "USB-C for AI" analogy holds up. Before USB-C, every laptop had a different charging port. Before MCP, Claude's tool connections and GPT's tool connections were separate implementations. MCP created a common connector.
What MCP standardizes:
- Tools: Functions or actions an agent can invoke (file reads, API calls, code execution)
- Resources: Data the agent can read (documents, DB records, file system)
- Prompts: Reusable prompt templates the server provides
As of April 2026, there are over 5,000+ MCP servers — GitHub Actions, Notion, PostgreSQL, Brave Search, browser automation, and almost every major tool you can think of.
When I first wired MCP into this blog's automation system, the thing that surprised me most was framework agnosticism. MCP servers I built for Claude Code worked in other MCP-compatible clients without modification. In practice there are edge cases where client feature sets differ, but the direction is sound.
What the 2026 MCP Roadmap Focuses On
The most important item on the 2026 MCP roadmap is solving horizontal scaling. Current Streamable HTTP transport maintains stateful sessions — which fights with load balancers. When requests get routed to different server instances, sessions break. The roadmap aims to make MCP servers genuinely stateless.
The second priority is discovery standardization via .well-known. Right now you have to connect to an MCP server to know what it offers. The goal is to serve capability metadata without a live connection.
My earlier post on WebMCP gets into how MCP server implementation works under the hood, if you want a concrete picture.
A2A: Agents Talking to Each Other
A2A (Agent2Agent) was announced by Google in April 2025 and donated to the Linux Foundation in June 2025. The purpose is different from MCP: standardize how AI agents discover, communicate with, and delegate to each other.
If MCP is "agent ↔ tool," A2A is "agent ↔ agent."
The problem A2A solves: suppose you have a travel booking agent, a hotel search specialist agent, and a flight search specialist agent. How does the booking agent delegate tasks to the specialists? MCP doesn't handle this. That's A2A's domain.
A2A v1.0 Core Concepts
A2A v1.0, released in early 2026:
Agent Card: A JSON document where an agent advertises its capabilities. When a client agent needs to find the right specialist, it reads Agent Cards.
Task-based communication: Interactions are oriented around Tasks. Tasks can complete immediately or run long, with state synchronization built in.
Signed Agent Cards (the v1.0 headline feature): Cryptographic signatures allow receiving agents to verify that an Agent Card was issued by the domain owner. This makes decentralized agent discovery viable — you can filter fake agents.
By April 2026, 150+ organizations have adopted A2A, with production deployments at Microsoft, AWS, Salesforce, SAP, and ServiceNow.
Honest take: when I first read the A2A spec, I was skeptical about practical safety. Agents delegating directly to other agents sounds elegant, but the trust model gets complicated fast. v1.0's Signed Agent Cards are moving in the right direction, but I'd want to see more production validation before treating it as battle-hardened infrastructure.
A separate post covers A2A + MCP production hybrid architectures — specifically how to layer these two protocols without creating a mess.
Open Responses: OpenAI's Bet on API Compatibility
Open Responses is an open spec published by OpenAI in February 2026. It operates at a different level from MCP and A2A. Those two address how agents communicate; Open Responses addresses how to standardize agentic workflow APIs.
The spec is built on OpenAI's Responses API — the successor to Chat Completions — and the pitch is: let's open this standard so that other model providers can offer the same interface. If you write agentic code against the Responses API, it should run against Hugging Face models, local inference, or any other compliant provider without rewriting your integration.
Ecosystem support: Hugging Face, Vercel, OpenRouter have signed on. Ollama, vLLM, and LM Studio support it for local inference. The spec documentation and conformance testing tools are at openresponses.org.
My honest take: Open Responses is complementary to MCP and A2A, not competing. But I don't see a compelling reason to prioritize it in most production stacks right now. Large-scale production validation is thin. The bet that other vendors will adopt OpenAI's API design as a universal standard is real, but unproven at scale.
Side-by-Side Comparison
| MCP | A2A | Open Responses | |
|---|---|---|---|
| Purpose | Agent ↔ Tool connectivity | Agent ↔ Agent collaboration | Agentic API loop standardization |
| Analogy | USB-C (universal connector) | HTTP (for agent networks) | REST API design standard |
| Origin | Anthropic → AAIF | Google → Linux Foundation | OpenAI |
| Current version | 2025-11-25 | v1.0 (early 2026) | Beta |
| Ecosystem maturity | High (5,000++ servers) | High (150+ orgs) | Low (early stage) |
| Transport | Streamable HTTP, stdio | JSON-RPC, gRPC | WebSocket, HTTP |
| Security model | OAuth, per-server auth | Signed Agent Cards | Under specification |
| When to use | Any time tool access is needed | Multi-agent task delegation | OpenAI-compatible workflows |
The most important thing to understand: MCP and A2A are AND, not OR. Most production multi-agent systems in 2026 use both. Each agent connects to its own tools via MCP; agents coordinate via A2A.
How They Layer in Practice
A concrete architecture example:
Scenario: Automated research system
Orchestrator Agent
├── (A2A) → Web research specialist agent
│ └── (MCP) → Brave Search MCP server
│ └── (MCP) → Web scraping MCP server
├── (A2A) → Document analysis specialist agent
│ └── (MCP) → File system MCP server
│ └── (MCP) → PDF processing MCP server
└── (MCP) → Results storage MCP server
The orchestrator delegates via A2A; each specialist accesses its own tools via MCP. Open Responses could sit at the orchestrator's external API interface if you need OpenAI-compatible endpoint exposure.
My breakdown of Claude Code agentic workflow patterns goes deeper on implementing this kind of layered architecture.
What to Learn Right Now
Practical priority order:
Learn immediately: MCP
If you're building agents, start here. Reasons:
- 5,000++ server ecosystem already exists
- Claude Code, OpenAI Agents SDK, LangGraph all support it natively
- Streamable HTTP is the settled standard; spec is stable enough for production
- Anthropic's Agent Skills standard builds directly on MCP, creating increasingly powerful patterns
Medium-term: A2A
If you're planning multi-agent production systems, study A2A. 150 org adoption, Linux Foundation governance, v1.0 stability — it's ready. But I'd still want to see more validated production case studies before relying on the Signed Agent Cards trust model for anything security-critical.
Monitor: Open Responses
Unless you have a specific OpenAI-compatibility requirement today, there's no urgency. Subscribe to updates; don't architect around it yet.
One more thing worth noting: both MCP and A2A are now under the Linux Foundation. This isn't a standards war — it's the same foundation solving two different layers of the same problem. That's the clearest signal that 2026 is different from 2024.
My Take
MCP is the tool to use right now. It's the layer that gives agents access to the external world, and the ecosystem is mature. A2A is worth learning seriously if you're thinking about multi-agent systems — v1.0 is production-ready in most respects. Open Responses is worth following but not yet worth building around.
Stop thinking about these as competing standards. They solve different problems and most serious systems need all three eventually. My working heuristic: MCP first, A2A when you need multi-agent delegation, Open Responses when the ecosystem catches up.
And your choice of AI agent framework is tightly coupled to this — different frameworks have significantly different levels of MCP and A2A support.
Top comments (0)