A2A and MCP Are Not the Same Thing. Here Is How They Stack.

It is 9 a.m. on a Tuesday. A planning agent in your Slack-connected workflow identifies a contract that needs legal review, spins up a specialist legal agent, delegates the task, and posts a summary back to the channel - all without a human routing anything. If you have seen that demo, you have seen A2A and MCP working together. What the demo does not show is the static config file someone had to hardcode before any of it ran.

That gap is the honest story of where the agentic protocol stack is right now.

What MCP actually does (and what it leaves out)

MCP - Model Context Protocol - is the vertical layer. It answers one question: how does a single agent connect to external capabilities? Databases, APIs, file systems, code execution, internal docs. MCP handles tool integration: the agent-to-capability relationship. An agent uses MCP to call tools, read resources, and execute prompts. That's the whole job. It does not coordinate agents. It does not handle delegation. It does not know another agent exists.

By March 2026, MCP had reached 97 million monthly SDK downloads - comparable scale to the React npm package, but achieved in 16 months instead of three years.

The ecosystem is mid-transition in two dimensions simultaneously: from stdio to hosted transport, and from API keys to OAuth 2.1.

The clearest heuristic: if a server was launched by a vendor after January 2026, assume hosted endpoint plus OAuth 2.1 unless the docs say otherwise.

One thing that number obscures: 22,000+ servers are now available, but growth has brought more serious security challenges, including the OX Security systemic RCE disclosure in April 2026 and multiple new CVEs. The registry count is a measure of breadth, not maturity. Choose servers that have been under production load.

What A2A actually does (and what it just fixed)

The Agent-to-Agent protocol, released by Google in April 2025, addresses a different problem than MCP. Where MCP connects an agent to tools and data, A2A connects one agent to another.

The core mechanism is the Agent Card: each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements - analogous to a service descriptor in microservice architectures. A planning agent fetches a card, confirms the sub-agent can handle the task, and delegates. The sub-agent returns a structured artifact. No shared internal state, no proprietary SDK.

The protocol advanced from v0.3.0 in July 2025 - which introduced streaming-first transport and enhanced Agent Cards with capability negotiation - to v1.0.0 in January 2026, which marked the transition from experimental to production-ready status, introduced signed Agent Cards for cryptographic verification, and codified the discovery and trust mechanisms identified as gaps in earlier analyses.

Signed Agent Cards are the part worth understanding. By adding a cryptographic signature to the Agent Card, a receiving agent can verify that the card was actually issued by the domain owner. Without this, an attacker could stand up a fake Agent Card and redirect other agents into a card forgery attack. Signed Agent Cards are effectively the trust model that makes decentralized discovery viable at all.

More than 150 organizations now participate, the GitHub repo has passed 22,000 stars, and production deployments exist inside Azure AI Foundry and Amazon Bedrock AgentCore.

The part no one demos: discovery still requires static config

Here is the non-obvious gap. A2A specifies how agents communicate once they find each other. The harder problem is finding them in the first place.

Most production multi-agent deployments in early 2026 use static configuration - agent URLs, credentials, and capabilities are hardcoded or environment-variable-driven. This is operationally simple and makes debugging straightforward, but it does not scale to dynamic agent ecosystems where capabilities change and new agents are added regularly.

A2A proposes a /.well-known/agent.json endpoint for URL-based discovery: if you know an agent's domain, you can fetch its capabilities without prior coordination. Adding a new capability to an agent requires only updating the card, not reconfiguring every consumer. But you still have to know the domain first. There is no registry DNS for agents yet.

No protocol mandates structured logging or OpenTelemetry integration. Every production team builds this independently, leading to fragmented monitoring approaches that make cross-system debugging difficult.

The two protocols also have a governance gap between them. A reported Q3 2026 MCP/A2A joint specification effort is the first formal step toward protocol-level bridges, but it is not yet complete. Until that lands, teams wire the two protocols together with custom glue code.

How MCP and A2A actually compose in a real workflow

The layered model is simple in theory. MCP provides the universal tool access layer. A2A provides the agent coordination layer. In practice, a planning agent uses A2A to discover and delegate to a specialist agent, and both agents use MCP to reach the tools they need. The two protocols never overlap; they run at different layers.

For teams making architecture decisions today, the sequencing recommendation is clear: start with MCP to establish the tool access foundation, add A2A when multi-agent coordination becomes necessary.

One note on the upcoming MCP spec: the 2026-07-28 release candidate introduces substantial changes, including a stateless protocol core, a formal extension framework, redesigned task support, and authorization improvements. Because it contains breaking changes, production architects should distinguish between the current stable specification and the upcoming revision rather than treating release-candidate behavior as universally available.

A teammate like Beagle sits on the MCP side of this stack - connected to your tools and docs, answering lookups in-channel. The A2A coordination layer is what a planning agent would use to delegate to Beagle from another system. The two roles are distinct, and conflating them is the most common architecture mistake right now.

A2A protocol MCP: common questions

What is the difference between MCP and A2A?

MCP (Model Context Protocol) connects a single agent to external tools and data sources. A2A (Agent-to-Agent) connects one agent to another agent for task delegation and coordination. They solve different problems at different layers of the stack and are designed to be used together, not instead of each other.

Is A2A production-ready?

A2A v1.0 reached production-ready status in early 2026, with v1.0.1 released in May 2026. It is supported by Azure AI Foundry, Amazon Bedrock AgentCore, and 150+ organizations. The protocol core is stable. What is not standardized yet is dynamic agent discovery and cross-system observability - most production teams still use static configuration.

Do you need both MCP and A2A for a multi-agent system?

In most cases, yes. MCP handles the tool and data access each agent needs. A2A handles coordination between agents. A single-agent system that calls tools only needs MCP. A system where a planning agent delegates to specialist agents needs both. The protocols compose at different layers and do not overlap.

When will MCP and A2A have a joint interoperability spec?

A joint MCP/A2A interoperability specification - with reference implementations and compliance test suites - is expected in Q3 2026, developed under the Linux Foundation's Agentic AI Foundation. A Q3 release candidate has been reported. Until it ships, teams building systems that span both protocols are writing their own integration glue.

What are Signed Agent Cards in A2A v1.0?

Signed Agent Cards are the trust primitive added in A2A v1.0. Each Agent Card carries a cryptographic signature from the domain owner. A receiving agent verifies the signature before accepting a delegation, preventing attackers from publishing fake cards that redirect agent traffic. Without them, decentralized agent discovery is vulnerable to card forgery attacks.