Standards Wars: MCP, A2A, and the Fight for the Agent Layer

Every few years the field picks up a new favorite phrase, and for the last eighteen months or so the favorite has been "protocol." MCP is a protocol. A2A is a protocol. OpenAPI is the original protocol. Every blog post about agents has a diagram with a box labeled "protocol layer" in it.

I think this is one of those topics where it's easy to operate with a vague mental model of "there are a bunch of new acronyms and they all kind of compete." I certainly did for a while. That's not actually what's happening. What's happening is that a specific two-layer stack is forming under the agent ecosystem, and the interesting fight is at specific layers, not at the ecosystem level.

This post is an attempt to hand you the mental model I use to reason about it: what each protocol is actually for, where they overlap, where they don't, and why I think both MCP and A2A survive the next few years rather than one of them winning outright.

Integration tax

Before the protocols, consider the world they showed up into.

You have some LLM host (Claude Code, Cursor, a custom app). You want it to read from a Postgres database, search your company's internal docs, open tickets in Jira, send a Slack message, and run a Python sandbox. Each of those integrations is a bespoke piece of glue: you write a function, register it with the model's function-calling format, handle auth, serialize the arguments, parse the response, and hope nothing in the wire format drifts.

Do that across three hosts and five tool providers and you have fifteen integrations to maintain. Nobody ever does all fifteen, so the typical shape of the world is "Claude Code has great GitHub integration but no Jira, Cursor has Slack but no Postgres, and your custom app has everything half-wired." Every tool provider ends up writing the same integration three times. Every host ends up writing the same integration five times. The ecosystem's total integration cost scales as $N \times M$.

That quadratic tax is the pressure that made MCP inevitable. If you can convince everyone to speak one wire format, each new server needs one adapter instead of $N$, each new client needs one adapter instead of $M$, and the integration cost collapses from $N \times M$ to $N + M$.

This is exactly the same shape as every previous integration-standard fight in computing. USB collapsed dozens of peripheral buses into one. HTTP collapsed a jungle of document-transfer protocols into one. OAuth (eventually) collapsed bespoke auth flows into one.

The real question, then, is not whether a standard wins but which standard wins at which layer.

The two standards (and the incumbent)

There are three protocols doing real work in the agent stack right now. Let me name them precisely, because the casual press tends to mash them together.

OpenAPI. The incumbent. OpenAPI (formerly Swagger) describes a REST API as a JSON or YAML document: endpoints, methods, parameters, request bodies, response schemas, auth. It's been around in usable form since about 2011, went through a major 3.0 revision, and hit 3.1 in 2021. Millions of APIs have OpenAPI specs. When OpenAI launched function calling in June 2023, a lot of the world's first instinct was "great, I'll just point it at my OpenAPI spec," and a cottage industry popped up to convert OpenAPI documents into function-calling tool definitions. It works. It's the baseline.

MCP (Model Context Protocol). Anthropic, November 2024. A JSON-RPC protocol for a model-equipped client to connect to a "server" that exposes tools, resources, and prompts. Local servers run as subprocesses over stdio; remote servers run over streamable HTTP. The client asks tools/list, gets a schema back, and can then tools/call any tool. It deliberately stops at the model-to-tool boundary. Agents talking to agents is explicitly out of scope.

A2A (Agent2Agent). Google, April 2025. A protocol for one agent to hand a task to another agent. Agents publish an "Agent Card" at a well-known URL that advertises their skills, input modes, and capabilities. Another agent reads the card, sends a task, streams updates over server-sent events, and eventually receives artifacts back. It deliberately stops at the agent-to-agent boundary. Tools are out of scope.

The single most important thing about this table is that MCP and A2A are not solving the same problem. The press framing is usually "Anthropic's standard vs Google's standard," but that framing misses the point. They sit at different layers of the same stack. An agent can speak MCP downward to its tools and A2A sideways to its peers at the same time, and plenty of real systems already do.

Where the layers actually live

Let me try to build the layer model more carefully. The agent stack has a small number of jobs that need doing, and each protocol covers a specific subset. Click around below:

A few things that jumped out for me when I first drew this diagram for myself.

The first is that OpenAPI is genuinely enough for one narrow purpose: describing what a tool is and what it expects. The instinct to reach for "we'll just use OpenAPI" usually means the schema piece. And the schema piece of OpenAPI is excellent. JSON Schema is a solved problem and everyone has parsers for it. The trouble is that OpenAPI says nothing about how a model should call a tool, how a tool should stream results back, how a session persists across calls, or how any of this plays with auth flows designed before "an LLM on your laptop wants to hit your API" was a thing. OpenAPI is a schema. A protocol for agents is a different object.

The second is that MCP's design choice to own the entire invocation path (transport + list + call + results) is what made it adoptable. You don't get to pick a transport, you don't get to pick a framing, you don't get to pick a tool-call format. The protocol makes those choices for you, and in exchange you get a universe of clients that already speak it.

The third is that A2A is filling a genuinely empty spot on the diagram. There was no real standard for "I am an agent, here are my capabilities, please send me a task" before April 2025. Every multi-agent framework invented its own conventions, and if you wanted two frameworks to interoperate you were writing adapters. A2A is an attempt to stop that.

MCP: the model-to-tool standard

Let me zoom in on MCP because it's the protocol most readers will actually touch first.

The architecture is three parts: a host (the application, for example Claude Code or Cursor), a client inside that host that speaks MCP, and a server that exposes tools. The client and server talk JSON-RPC 2.0. Local servers launch as subprocesses and communicate over stdio. Remote servers listen on an HTTP endpoint and communicate over a streamable-HTTP framing that supports server-pushed messages.

The protocol exposes three primitives: tools (model-invoked actions, what everyone focuses on), resources (data the host can surface, like a file's contents), and prompts (reusable templates the server hands to the host). In practice, tools are the headline feature. A tool definition is a name, a human-readable description, and a JSON Schema for its arguments. The model sees the description and the schema, decides when to call the tool, and the host routes the call through the MCP client to the right server.

The smallest possible demonstration of how straightforward this is:

import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
 
# Launch a local MCP server as a subprocess over stdio.
# This one is the reference filesystem server — it exposes read_file,
# write_file, list_directory, etc., scoped to a root path.
params = StdioServerParameters(
    command="npx",
    args=["-y", "@modelcontextprotocol/server-filesystem", "/tmp/demo"],
)
 
async def main():
    async with stdio_client(params) as (reader, writer):
        async with ClientSession(reader, writer) as session:
            await session.initialize()          # MCP handshake
            result = await session.list_tools()  # -> tools/list
            for t in result.tools:
                print(f"{t.name:20}  {t.description[:60]}")
 
            # Call one of them.
            out = await session.call_tool(
                "list_directory",
                arguments={"path": "/tmp/demo"},
            )
            print(out.content[0].text)
 
asyncio.run(main())

Two things to notice. First, there's almost no MCP-specific vocabulary in the code. You initialize, you list_tools, you call_tool. The model-facing side of the protocol is tiny on purpose. Second, swapping this server for any other MCP server (GitHub, Postgres, Slack, a custom one you wrote in an afternoon) doesn't change the client code.

The ecosystem has compounded in exactly the way you'd expect a two-sided market to. By early 2026 the public MCP server catalogs list thousands of servers; Cloudflare, Pipedream, Composio, and Anthropic's own registry each publish hundreds or thousands of remote MCP endpoints that an agent can plug into with a single config line. Every new server made every existing client more valuable, and vice versa.

A2A: the agent-to-agent protocol

A2A is earlier and less mature, which means it's a better place to watch a standard being born.

The core abstractions are:

Agent Card. A JSON document at a well-known URL (/.well-known/agent.json on the agent's host) that advertises what the agent does. It lists skills (with descriptions), supported input modes (text, files, structured data), authentication requirements, and capability flags (does this agent support streaming? long-running tasks?). Think of it as the Agent equivalent of a service's OpenAPI spec: "here's what I am, here's what you can ask me to do."

Task. The unit of work. One agent sends a tasks/send to another agent with a message, and gets back a task ID plus a task state. Tasks have a lifecycle (submitted → working → input-required → completed/failed/canceled) that both sides can observe. This is deliberately more stateful than a single HTTP request, because agent work just is more stateful than a single HTTP request.

Artifact. The output of a task. Instead of stuffing everything into a response body, an agent produces one or more named artifacts (a summary, a CSV, a follow-up plan) that the caller can fetch or subscribe to.

If that sounds more like a job-queue protocol than a request-response protocol, good, it should. The design explicitly recognizes that agent work often takes minutes or hours, that intermediate updates matter, and that structured streaming (via SSE) is how you keep the caller informed.

The conceptual overlap with MCP is small. An A2A agent that needs to hit its database uses MCP (or something MCP-shaped) to do so. An MCP client that discovers a "sub-agent" capability on a server isn't really doing MCP anymore; it's bumping into the lower edge of A2A's problem space. The two protocols are complements, not competitors, and everyone involved has said as much on the record.

What A2A hasn't done yet, at least as of early 2026, is hit the ecosystem inflection point. Adoption is real but small. The curve is still in its first year.

Minimal math: why standards win where they win

The economics of protocols are well-studied, and the intuition boils down to one line. The value of an ecosystem grows faster than the size of the ecosystem.

Metcalfe's observation about networks (roughly: a network's value scales with $n^2$ in the number of nodes) is a useful first approximation, though it overstates things at large $n$ and more recent analyses of real networks suggest something closer to $n \log n$. The exponent matters less than the shape. The value function is superlinear: doubling the number of MCP servers does more than double the value of the MCP client ecosystem, because every new server unlocks new use cases for every existing client.

Run the numbers for a moment with the $N \times M$ model from earlier. With 10 MCP clients and 10 MCP servers, a world without a standard requires 100 bespoke integrations. A world with a standard requires 20 adapters. The ratio is $\frac{N \times M}{N + M}$, which for $N = M$ is roughly $N/2$. At 10-and-10, the standard is saving 5× the work. At 100-and-100, it's saving 50×. At 1000-and-1000, 500×.

The integration savings compound.

The less obvious corollary: the tipping point gets harder to cross, not easier, as more alternatives exist. A second standard that does the same thing at the same layer doesn't get to start fresh; it starts behind, and it needs to overcome not just the alternative's current adoption but its compounding rate. This is why OpenAI adopting MCP in March 2025 was a bigger deal than the press coverage suggested. It wasn't just "another vendor got on board." It was "the biggest plausible alternative bucket of energy stopped being a potential rival and became reinforcement." After that, any competing model-to-tool standard had to beat a curve that wasn't slowing down.

A2A doesn't face that problem, because it isn't competing with MCP at MCP's layer. The agent-coordination slot was empty.

What a single call actually looks like

Let me walk through one concrete request so the pieces stop being abstract.

Say a user in Claude Code asks "what files are in my project's /src folder, and summarize config.ts?" The runtime path:

1. The Claude Code host has an MCP client running. At startup it called tools/list on each configured server. The filesystem server advertised list_directory and read_file, among others. Those tool definitions are in the model's context as JSON Schemas.
2. The model decides to call list_directory(path="/src"). The host intercepts the tool call, routes it through the MCP client to the filesystem server over stdio, receives back a list of entries, and returns the result to the model as a tool-call response.
3. The model now decides to call read_file(path="/src/config.ts"). Same routing, same return path.
4. The model produces a natural-language summary grounded in the file contents.

The whole round trip happened over a protocol the user never touched directly. From the model's side, this looked like calling two functions. From the tool provider's side, they wrote one MCP server and every MCP-speaking host got the benefit.

Now imagine the same user asks "and schedule a kickoff meeting with the design team next Tuesday." If scheduling is just another tool on an MCP server the host already speaks, great, same path. But suppose scheduling is owned by a separate autonomous agent that knows everyone's calendars, preferences, and meeting norms. That's where A2A enters. The Claude Code host can, via an A2A client, send a tasks/send to the scheduling agent with "kickoff with design team next Tuesday," receive a task ID, subscribe to its SSE stream, get back a proposed time and an artifact containing the draft invitation, and surface that to the user for confirmation. The scheduling agent probably used MCP under its own hood to hit the calendar API. Two protocols, two layers, one user ask.

That composition is the whole point. Neither protocol alone delivers the experience.

Misconceptions

"MCP and A2A are competitors." They aren't. They sit at different layers of the stack. MCP connects a model (or a model-equipped application) to tools. A2A connects agents to other agents. An agent can and usually will speak both: MCP downward to the tools it uses, A2A sideways to the peers it delegates to. The framing as a fight makes for good headlines but it doesn't map to what either spec is actually doing. If you want a real rivalry, look at the tool-definition-schema layer, where OpenAPI and MCP's tool definitions overlap and somebody is going to end up wishing they'd picked the same one.

"Standards always converge to one winner." Sometimes (USB, HTTP, JSON). Often they don't (messaging, calendar sync, sign-in, instant messaging, every pub-sub format ever). Convergence happens when the problem is homogeneous and the incentives align on one side. It fails when the problem splits across layers or when the economic incentives of big players diverge. The agent stack has both. I expect MCP to dominate the model-to-tool layer, A2A or an A2A-descendant to dominate the agent-coordination layer, OpenAPI to remain the canonical schema-for-REST-APIs, and for a bunch of smaller protocols (authentication, identity, billing) to settle independently. There is no reason the agent stack should have fewer protocols than, say, the web stack.

"OpenAPI is enough for agents." It's enough for tool definition, if you squint. It's not enough for tool invocation in an agent loop. OpenAPI says nothing about session state, nothing about streaming results, nothing about how a model should emit a call, nothing about server-pushed updates. You can get far with an OpenAPI-to-function-calling shim, and plenty of teams do, but you will eventually hit the wall where your tools want to stream intermediate results, hold session state, or push notifications back to the agent. That's where MCP's design pays off.

"Standards are settled by spec quality." They're settled by adoption. Adoption is settled by who ships useful servers and clients fast enough for the network effect to catch. Spec quality matters at the margin (a truly terrible spec will fail to attract implementers), but above a floor it's the ecosystem dynamics that decide. Betamax was the better spec. HD-DVD was, arguably, the better format. AMP had Google's weight behind it. None of those outcomes were about spec quality in isolation.

What's next

The fight over protocols is really a fight over who owns the agent layer, and the honest answer in early 2026 is that nobody owns it yet. MCP has won the model-to-tool slot faster and more decisively than the initial adoption curves suggested. A2A is the leading candidate for the agent-coordination slot but still has its inflection point ahead of it. OpenAPI keeps quietly doing its schema-for-REST-APIs job and isn't going anywhere. I think the interesting question for the next few years is not "which protocol wins" but "what do the bridge libraries look like" (OpenAPI-to-MCP converters, MCP-inside-A2A-agents, A2A-over-MCP-tunnels). Standards wars end, mostly, in interoperability bridges that let everyone keep their preferred acronym while quietly doing the same thing underneath.

The next post zooms out further and looks at how the field arrived at this point: a short history of the field, 2013–2026, from word2vec through the transformer, GPT scaling, ChatGPT, open-weight releases, and the agent era, with the inflection points that built today's stack.

Additional reading (and watching)

• Anthropic. (2024). Introducing the Model Context Protocol. Launch post framing MCP as the fix for the $N \times M$ integration problem between AI applications and data sources.

• OpenAPI Initiative. (2021). OpenAPI Specification 3.1.0. The canonical spec for describing REST APIs; the version that finally aligned with JSON Schema draft 2020-12.

• Model Context Protocol. (2024–). Specification. The living MCP spec: JSON-RPC 2.0, stdio and streamable HTTP transports, tools/resources/prompts primitives.

• Google. (2025). Agent2Agent Protocol (A2A) specification. Spec and reference implementations for agent cards, task lifecycle, and artifact messaging.

• Anthropic. (2026). MCP server registry. Public listings showing the scale of the MCP server ecosystem by early 2026; cross-referenced with Cloudflare and Pipedream catalogs.

• Google & Anthropic. (2025). A2A and MCP are complementary. Both teams have been explicit that the protocols sit at different layers and are designed to compose.

• Briscoe, B., Odlyzko, A., & Tilly, B. (2006). Metcalfe's Law is Wrong. IEEE Spectrum. The $n \log n$ refinement of Metcalfe's original $n^2$ claim; still superlinear, which is all the intuition needs.

• OpenAI. (2025). MCP support in the Responses API. The adoption moment that turned MCP from "Anthropic's protocol" into "the protocol."

• Cloudflare. (2025). Remote MCP servers on Cloudflare. How remote MCP over streamable HTTP and OAuth made hosted MCP viable at scale.

• LangChain. (2025). A2A interoperability in LangGraph. An early cross-framework A2A adoption report that illustrates what the protocol looks like when it's doing real work.

• Schilling, M. A. (1999). Winners, Losers, and Microsoft (ch. on standards wars). The durable reference for why adoption curves, not spec quality, decide standards fights; useful context for the VHS/Betamax-shaped intuition.