Ask five engineers whether you should build on MCP or A2A and you will get five confident answers, most of them wrong. Not because the engineers are bad, but because the question itself is broken. It is like asking whether you need plumbing or roads. You are not choosing. You are sequencing.

Here is the sentence worth taping to your monitor: MCP connects an agent to your tools. A2A connects an agent to other agents. One goes down into your systems. The other goes sideways across organisational lines. Most teams need the first one and quietly pretend to need the second.

That distinction just got sharper, because MCP shipped its biggest revision since launch on 28 July 2026, and it broke things on purpose. If your team is still working from a 2025 blog post, you are planning around a protocol that no longer exists.

The Question Everyone Is Asking Backwards

The “protocol war” framing sold a lot of newsletters and predicted nothing. Both standards now sit under the Linux Foundation. Anthropic donated MCP to the Agentic AI Foundation in December 2025. Google handed A2A over the same year. Neutral governance is the opposite of a war. It is two committees agreeing to stay in their lanes.

So stop asking which one wins. Ask instead: what is on the other end of the connection I am building? If the answer is a database, a ticketing system, or an internal API, that is MCP. If the answer is a piece of software somebody else operates and updates without telling you, that is A2A.

What MCP Actually Is

The Model Context Protocol is a standard way for a model to find out what tools exist and then use them. Anthropic open-sourced it in November 2024. Eighteen months later it is infrastructure, not a curiosity. Across the Tier 1 SDKs it pulls close to half a billion downloads a month, and both the TypeScript and Python SDKs have crossed a billion downloads in total.

Those numbers are not vanity metrics. They tell you the integration you build this quarter will still have a maintained SDK in three years, which is the only thing that actually matters when you pick a standard.

The Stateless Rewrite Changed Everything

The headline change in the 2026-07-28 specification is that MCP stopped being a stateful protocol. The old initialize and initialized handshake is gone. So is the Mcp-Session-Id header. Every request now carries its own protocol version, client identity and capabilities, which means any request can hit any server instance behind an ordinary round-robin load balancer.

If that sounds like plumbing trivia, consider what it removes. No sticky sessions. No draining connections on deploy. No shared session store. Cloudflare put it plainly: an MCP server is now an ordinary HTTP workload that runs in a Worker with no stateful infrastructure at all.

What Broke, and What You Get Back

Breaking changes are the price. Server-initiated requests such as elicitation and sampling used to need a stream held open. They now use Multi Round-Trip Requests, where the server returns an input_required result describing what it needs and the client retries with the answers attached. Roots, Sampling and Logging are deprecated. So is the legacy HTTP and SSE transport.

In return you get things production teams actually asked for. Method and tool names travel in the Mcp-Method and Mcp-Name headers, so your gateway or WAF can route, rate limit and meter without parsing JSON bodies. Tool lists carry ttlMs and cacheScope hints in deterministic order, so clients can cache catalogues without wrecking upstream prompt caches. And there is finally a formal deprecation policy with a twelve month minimum window, which means you can plan upgrades instead of firefighting them.

The results are measurable. One framework maintainer reported cutting package size by roughly 83% and running 25% faster on the new client and server split. Honeycomb reported that nearly 20% of its monthly interactive queries now come from agents rather than humans.

How MCP Handles Authorization Now

Authorization is where teams burn the most time, and this release tightened it. Authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code, which closes an authorization server mix-up hole. Client credentials are now bound to the issuer that minted them, so no reuse across servers.

The bigger shift is that Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents, where a client identity is simply a URL pointing to a JSON document that client controls. DCR still works, but it is slated for removal after summer 2027. If your identity team has not seen CIMD yet, that meeting is overdue.

What A2A Actually Is

Agent2Agent came out of Google in April 2025 and now lives at the Linux Foundation. Where MCP asks “what tools can I use,” A2A asks “who else can do this work, and can I hand it to them?”

The Agent Card, Explained Simply

An agent publishes an Agent Card, a machine readable description of what it can do and how to reach it. Another agent reads that card, sends a task and tracks it to completion. Neither side knows or cares how the other is built.

Think of it as a business card with a contract stapled to the back. You do not need to know how the accountant does the books. You need to know they do books, what they need from you, and how you will hear back.

Where A2A Is Actually Running

The Linux Foundation reported that A2A passed 150 supporting organisations in its first year, up from around 50, with more than 22,000 GitHub stars. Backers include AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow. Version 1.0 landed as the first stable spec, with production SDKs in Python, JavaScript, Java, Go and .NET.

It is in the platforms too. Microsoft wired it into Azure AI Foundry and Copilot Studio. AWS supports it through Bedrock AgentCore Runtime. A related effort, the Agent Payments Protocol, launched with more than 60 organisations behind it to handle agent-driven transactions.

MCP vs A2A: The Side-by-Side

The Rule of Thumb That Saves You a Quarter

Draw a line around everything your team can deploy. Inside that line, use MCP. Crossing that line, use A2A. That is the whole heuristic, and it is right far more often than any vendor diagram.

Signs You Only Need MCP

• Your agent reads and writes systems you control, such as Postgres, Jira, Salesforce or an internal API.
• Every component ships from your own pipeline.
• Your team is under twenty engineers and running one assistant.
• You cannot name a specific external agent you would delegate to today.

Signs You Genuinely Need A2A

• A vendor or partner has published an Agent Card you can actually call.
• Work has to cross a company boundary without a human forwarding an email.
• You are the vendor, and your customers want to reach you agent to agent.
• Different business units run different agent platforms and refuse to consolidate. Be honest, this is common.

The Security Conversation Nobody Wants to Have

Here is the part that gets skipped in the excitement, and it is the part that will end up in your incident review.

What the NSA Actually Said

In May 2026 the NSA’s Artificial Intelligence Security Center published a Cybersecurity Information Sheet titled Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. It is not a hit piece, but it is not a reassurance either.

The agency flagged serialisation risks, unclear trust boundaries and agent misuse, and noted that agentic systems introduce genuinely new problems: dynamic tool invocation, implicit trust relationships and context sharing. Its blunt conclusion is that established cyber defence strategies do not adequately address these risks, and that you cannot patch them at the interface or endpoint. The agentic environment has to be treated as a continuum, because a wrong assumption at one stage compounds into an exploitable condition at another.

Read that again if you are about to connect an agent to anything holding customer data.

Three Controls to Put in Place This Week

1. Classify before you connect. Align tools and models with data classification zones. An agent with access to a public docs server should not share a context window with one holding payroll.
2. Log at your layer, not theirs. MCP still lacks standardised audit trails and a defined multi-tenancy model. When an agent calls a tool on its own, cost attribution and rate limiting are on you.
3. Treat servers as supply chain. Pin versions, review exactly what each server can reach, and never hand a third-party server a credential you would not paste into a public Slack channel.

What This Actually Costs You

Nobody puts protocol migration in the budget, and then it eats a sprint.

The Migration Nobody Budgeted For

If you built an MCP server in 2025, the stateless move is a real change, particularly if you leaned on session identifiers. The good news is that the migration path is documented and backward compatibility is deliberate. A single endpoint can serve both new stateless requests and older Streamable HTTP clients while you move, so most clients reconnect without config changes.

The sensible pattern is to run a strict stateless route beside your existing sessionful route, migrate features across, let active sessions drain, then delete the legacy path inside the twelve month window. Boring, and it works.

A 30-Day Adoption Plan

1. Days 1 to 5. Pick one internal system. Check the registry before you build anything. Keep it read-only.
2. Days 6 to 12. Wire one agent to that one server. Log every tool call. Watch what it does when nobody is looking.
3. Days 13 to 20. Add write access to a single low-stakes action, with an approval step in front of it. MRTR exists exactly for this.
4. Days 21 to 30. Review the logs with your security lead. Only then widen access, and only then look at whether an A2A boundary exists for you at all.

Common Mistakes I See Teams Make

• Building A2A first. Agents that talk to each other but cannot touch your data are an expensive group chat.
• Copying a 2025 tutorial. Half of them assume a session handshake that no longer exists.
• Installing registry servers unreviewed. A registry entry is not an endorsement.
• Skipping the approval step. The first time an agent refunds the wrong customer, you will wish you had spent the afternoon.
• Waiting for a winner. Both protocols are stable and governed. Waiting costs you a year and buys you nothing.

Conclusion

The protocol war everybody predicted turned into something far more useful: a stack with a clear order. MCP is the layer that gives your agent hands. A2A is the layer that lets it hand work to a stranger. You almost certainly need the first one now and the second one later, if at all.

So start small. Connect one system, keep it read-only for a fortnight, log everything, and put a human in front of the first write. Add A2A the day a partner gives you a real endpoint, not the day a slide deck mentions it. The teams that will look smart in a year are not the ones who picked the right side. They are the ones who shipped one boring integration properly, then another.

Frequently Asked Questions

1. Is A2A replacing MCP, or the other way round?

Neither. They sit at different layers and are usually deployed together. Both are Linux Foundation projects with independent governance, which makes a takeover by either one unlikely.

2. Do I have to migrate to the 2026-07-28 MCP spec right away?

Not immediately. Deprecated features get a twelve month minimum window, and endpoints can serve old and new clients side by side. But new work should target the stateless spec, because that is where the SDK effort is going.

3. Should I build my own MCP server or use an existing one?

Check the registry first. Build only when your internal system has no server, and start read-only. Building is easier than it was, which is exactly why people build servers they did not need.

4. Is MCP safe enough for regulated data?

With careful design and heavy logging, teams are doing it. The NSA guidance is worth reading in full before you decide, because it names the gaps clearly rather than pretending they do not exist. Classify your data zones first.

5. What about WebMCP and the other emerging protocols?

Watch them, do not build on them yet. MCP and A2A both cleared the only bar that matters: neutral governance plus production SDKs maintained by more than one vendor. Very few contenders have.