MCP, A2A and WebMCP: the map of agent protocols in 2026

The MCP SDKs saw 97 million downloads in a single month. WebMCP has an accepted specification, an implementation in Chrome and no major agent consuming it.

Both get called an "agent protocol" in the same paragraph, across almost every piece of writing on the subject.

They are three protocols, three different layers and three stages of maturity that look nothing alike. This post maps what each one solves, where each one stands, and what none of the three solves.

I verified every number here on 28 August 2026. This is the fastest-ageing area in the whole cluster.

The confusion starts because the three solve things that sound alike and are not.

The sentence that organizes it all fits on one line: MCP connects the tool, A2A connects the peer, WebMCP connects the page.

If you want the walkthrough for connecting a server, it sits in MCP in practice. The question here is different: which of these protocols deserves attention now, and why.

On 9 December 2025, the Linux Foundation announced the formation of the Agentic AI Foundation, with three founding projects donated by three different companies (Linux Foundation, accessed 28 August 2026).

The three add up to use across about 40,000 open-source projects.

The platinum member list is the most eloquent data point: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. Cisco, IBM, Oracle and Salesforce take part at other tiers. These are companies that compete over almost everything, sitting in the same foundation to look after the connection layer.

A2A had walked the same path earlier, donated by Google to the Linux Foundation in mid-2025.

What that changes in practice deserves a plain statement: a protocol under a neutral foundation is less exposed to a unilateral vendor decision. It removes no risk of change, and it cuts the risk of one company closing the specification because its strategy moved.

One side note closes a loop in this cluster. AGENTS.md, one of the three founders, is the same file whose ETH Zurich study appeared in the four pillars of context: written by a human it yields about 4 points; generated by an LLM it makes the result worse. The standard reached a foundation before the research on how to fill it had matured.

MCP's numbers in March 2026 explain why it stopped being a topic of discussion and became an assumption.

That is 97 million monthly SDK downloads in March 2026, against about 2 million at launch, and more than 10,000 active servers across public and enterprise deployments.

The 2026 roadmap, published in March by lead maintainer David Soria Parra, names four fronts: transport scale, agent-to-agent communication, governance maturation and enterprise readiness.

The second front deserves recording, without turning into prophecy. Agent-to-agent communication is A2A's territory, and seeing it on MCP's roadmap means two protocols from the same foundation are advancing into the same space. That is a fact of 2026. The outcome remains open, and anyone writing that one will absorb the other is guessing.

A2A solves a problem that exists only when more than one owner does.

Two agents inside your system, written by you, need no protocol to talk. They need a function call. A2A earns its place when the agents are independent systems, with their own ownership, tools and trust boundaries.

Version 1.0 arrived in 2026 as the first stable, production-ready release, with multiprotocol support, enterprise multi-tenancy, modernized security flows and a migration path for early adopters. Today the protocol has more than 150 organizations taking part, passed 22,000 stars on GitHub and runs in production inside Azure AI Foundry and Amazon Bedrock AgentCore.

The most interesting feature in 1.0 is the least discussed: signed Agent Cards.

An Agent Card is an agent's calling card: what it can do, how to talk to it, which capabilities it exposes. With a cryptographic signature, the agent receiving the card can verify that the owner of that domain issued it. Verifiable identity before any interaction, across an organizational boundary.

In practice, the card carries the agent's name, the address where it answers, the capabilities it exposes and its authentication requirements. Without a signature, anyone can publish a card claiming to be a company's billing agent. With one, the receiver checks against the domain before sending anything.

That answers ASI07 from the OWASP list, insecure agent-to-agent communication, which I described in OWASP Top 10 for agents. The risk there is one agent trusting what another said without verifying. A signed card turns "I trust it because it answered" into "I trust it because the signature checks out".

<!-- [UNIQUE INSIGHT] -->

Here is the part most writing about protocols leaves out.

The idea is good and the inversion is elegant. Today, an agent that has to use a site takes a screenshot and guesses where to click, or leans on CSS selectors that break at the next layout change. With WebMCP, the site hands the agent the list of what it can do there and the exact parameters of each action. Control inverts: instead of the agent interpreting the page, the page declares its capabilities.

The architecture is worth understanding, in Patrick Brosset's formulation at Microsoft: the browser is the intermediary, and "the page never speaks MCP itself". The tools run inside the user's authenticated session.

Now the real state, as of 28 August 2026:

Claude, ChatGPT, Perplexity and Gemini consume no WebMCP tools. Google states that Gemini in Chrome will be the first.

WebMCP has a server and no client. The specification exists, the browser implements it, and nobody sits on the other end of the line.

It is a network effect in reverse, and it sustains itself: no site publishes because no agent consumes, and no agent consumes because no site publishes. Somebody has to move first, and the announced candidate is Gemini inside Chrome, which makes sense, because it is the one actor controlling both ends.

I record another detail I have seen in this cluster under a different name. The API moved from navigator to document in July 2026, and Chrome 150 deprecates the old location while still serving it. In agent observability it was gen_ai.system becoming gen_ai.provider.name. A specification in motion breaks code, and both times the signal was the same: whoever instrumented early paid for a rename.

All three carry calls. None carries policy.

On 1 July 2026, Richard Kang and Yudho Diponegoro published an analysis of governance gaps in agent interoperability protocols (arXiv 2606.31498, accessed 28 August 2026), examining MCP, A2A and ACP.

The study's third protocol, ACP, gets little coverage and deserves a line. It is another attempt to standardize agent-to-agent communication, with far less adoption than A2A. If you are choosing today, A2A is the bet with more critical mass. ACP enters here because the study assessed it alongside the others, and because the gaps it names hold for all three.

Five gaps:

The concrete examples the authors name as uncodifiable are specific: voting thresholds, permission hierarchies, audit trails and consensus mechanisms.

The practical consequence is direct and it applies to anyone assembling a multi-agent system right now. The protocol guarantees the message arrives and, in A2A's case, that it came from who it claims. It guarantees nothing about the agent having the right to ask for that.

That speaks to the argument in guardrails: a structural lock beats an instruction, and the lock has to exist somewhere. Since the protocol does not carry it, it is your code. A permission hierarchy between agents, today, gets built outside the protocol layer.

Two renames appeared in this post. WebMCP's, from navigator to document, in July 2026. And OpenTelemetry's, which became gen_ai.provider.name.

The pattern is clear. A new specification changes names. Early adopters pay the bill.

That is no reason to wait. It is a reason to adopt in a specific way.

Isolate contact with the protocol in one layer. One function talking to the MCP server. One module assembling the Agent Card. One file registering the WebMCP tools. A name change costs you one edit.

Pin the version. Never consume a protocol under development at whatever its latest version happens to be. Pin it, read the changelog, move up when you choose.

Record the date of the decision. Write in the code why you chose that version, and when. Six months on, someone will ask, and the answer saves an afternoon.

Prefer the protocol with a foundation. It is no guarantee against change. It is a guarantee that the change goes through a public process, with notice, rather than appearing in a release note.

None of that is specific to agents. It is the same care you take with any pre-1.0 dependency, and the only novelty is that many people are adopting these protocols without treating them as what they are.

The criterion is the problem, and not the novelty.

The WebMCP row deserves an explicit recommendation about timing. Implementing today bets on a consumer that has yet to exist. It makes sense for anyone with spare team capacity who wants to be ready when Gemini in Chrome flips the switch, and it makes none for anyone with a priority list.

The internal agents row deserves the same candor. Adopting A2A between two components of the same system, with the same owner and the same deploy, adds serialization, discovery and identity verification to solve what a direct call already solved. The criterion in when to delegate to a subagent holds here: the boundary has to be real for the protocol to earn its place.

<!-- [PERSONAL EXPERIENCE] -->

I went and checked before writing this section, and the answer is small.

The project has no MCP configuration file. No declared server, no protocol integration between the agent and the publishing tools. The tools doing the work, reading and writing files, running the build, generating the covers, assembling the schema, are local and native.

One real use exists, and it is occasional: a browser automation connection, used when I had to check indexing in Search Console. That is MCP doing what it does best, giving the agent a capability it lacked. Beyond that, no protocol.

The reason is not ideological. It is that one agent exists here, and the tools live on the same machine as it. The two conditions that justify A2A, more than one owner and a real trust boundary, do not apply to a one-person operation.

The WebMCP situation carries its own irony, because this blog is a site. In theory I could expose functions to agents: search posts by topic, list what shipped on a date, return an article's text. In February that would have looked visionary.

Today, with the information in the previous section, it would be work for zero consumers. It stays recorded as a deliberate, dated decision: revisit when some major agent starts consuming.

If this blog grew into a newsroom with several authors and agents under different owners, the conversation would change. That is not the case, and adopting a protocol before the boundary it solves exists is the most elegant way to add complexity while buying nothing.

I leave the three triggers that would change the decision on the record, because a decision without a trigger turns into dogma:

• A useful tool existing only as an MCP server. Then the protocol enters through necessity rather than architecture.
• Another person operating an agent over the same repository. Two trust boundaries justify verifiable identity.
• Some major agent starting to consume WebMCP. Then exposing the site's functions stops being a bet.

None of the three happened up to 28 August 2026. The day one does, I come back and update this section with the date.

What is the difference between MCP and A2A?

MCP connects an agent to tools, data and systems: it is the "what can I call" layer. A2A connects independent agents to each other, across trust boundaries and organizations: it is the "who do I talk to" layer. They do not compete; a project can use both. In practice, MCP is necessary in almost any useful agent, and A2A only starts to matter once more than one owner enters the picture.

What is WebMCP?

It is a browser interface letting a page expose typed functions to AI agents, instead of the agent taking a screenshot and guessing where to click. The site declares what it can do and which parameters each action requires, and the browser acts as the intermediary. The W3C accepted the specification in September 2025 and Chrome has run a public origin trial since version 149.

Do I need all three?

In most cases, no. Most projects need MCP and nothing else. A2A enters when agents from different organizations collaborate. WebMCP makes sense for anyone publishing a site that agents should be able to operate, and today that is a bet, because no major agent consumes those tools yet.

Does MCP still belong to Anthropic?

No. Anthropic donated MCP to the Agentic AI Foundation, created by the Linux Foundation on 9 December 2025, alongside goose from Block and AGENTS.md from OpenAI. The foundation has eight platinum members, AWS, Google, Microsoft and OpenAI among them. In practice, that cuts the risk of a single company changing the specification on its own.

What if I already adopted an old version?

Read the changelog before moving up, and migrate in one place. Both cases named in this post had an exit path: A2A published a migration path alongside version 1.0, and Chrome deprecates the old WebMCP API location while still serving it during the origin trial. Whoever isolated contact with the protocol in a single layer pays the migration in hours. Whoever spread the calls through the code pays in days.

Is it worth implementing WebMCP on my site now?

For most people, not yet. The specification is in a Chrome origin trial, it moved API location in July 2026, and none of the major agents consumes the published tools. Implementing today means building for a consumer that does not exist. It makes sense if you have spare team capacity and want to be ready when Gemini in Chrome starts consuming, which is the first announced move.

• MCP connects the tool, A2A connects the peer, WebMCP connects the page. Different layers, not competitors.
• All three sit under the Agentic AI Foundation since December 2025, with eight platinum members who compete with each other.
• MCP became infrastructure: 97 million monthly downloads and more than 10,000 servers.
• A2A earns its place through verifiable identity, the signed Agent Cards, and only where more than one owner exists.
• WebMCP has a server and no client. A good idea, with no consumer.
• None of the three expresses governance. Permission, auditing and resource limits are your code.

The cluster's next post picks up the thread A2A left open: agent identity, the privilege nobody revokes. The map of the five layers continues in the harness engineering pillar.