Skip to content
Guideintermediate

MCP vs A2A Protocol: Which Agent Standard Does Your 2026 Stack Actually Need?

The short version

The July 14 headlines called A2A an MCP rival. It isn't. MCP wires an agent to its tools, A2A wires one agent to another, and here is exactly when a builder needs each one.

Published July 15, 2026by Pondero Labs
Table of Contents

MCP vs A2A Protocol: Which Agent Standard Does Your 2026 Stack Actually Need?

On July 14, 2026, the headlines said Google, Microsoft, Salesforce, Snowflake, and ServiceNow had lined up behind an "MCP rival." They didn't. The protocol those companies rallied behind is A2A, and it competes with MCP about as much as TCP competes with HTTP. MCP is the wire from an agent to its tools. A2A is the wire from one agent to another. A real agent stack runs both. So the short version, before any of the spec detail: if you are wiring up your first agent workflow, start with MCP. Add A2A only once you have two agents that have to hand work back and forth.

That single correction saves you a week of building the wrong thing. We keep seeing teams treat this as an either/or bake-off, pick one, and then discover halfway through that the problem they actually have lives on the other layer. Both specs even say so out loud: the A2A docs describe MCP and A2A as addressing "distinct but highly complementary needs" (per the A2A v1.0 docs, fetched 2026-07-15).

Why the "protocol war" framing is wrong

Every one of these standards exists to kill the same monster. Call it the N times M problem: you have N agents and copilots, and M things they need to touch (databases, SaaS apps, other agents), and without a standard, every pairing is custom glue that grows quadratically while the value grows linearly (per the DEV Community state-of-standards writeup, July 7 2026). A standard turns N times M into N plus M. Each side implements the protocol once and the glue evaporates.

MCP solved that for the tool layer first, landing in late 2024. A2A showed up in April 2025 for the agent layer, positioned from day one as MCP's complement rather than its competitor. There was briefly a second agent-to-agent contender, IBM Research's ACP, and it folded. In August 2025 the ACP team wound down active development and merged its work into A2A under the Linux Foundation (per Zuplo, July 3 2026).

The "rival alliance" reading of the July 14 news gets the history backwards too. Google had already donated A2A to the Linux Foundation on June 23, 2025, launching the project with AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow as founding members (per Zuplo). Those names were on the door from the start. Nobody assembled them last week to gang up on Anthropic.

MCP: the agent-to-tool wire

MCP has two sides. Your agent is the caller. The MCP server is the capability provider, and it exposes tools, resources, and prompts the agent can pull in. A Claude session inside Cursor, an n8n workflow, a Make AI Agent, all of them sit on the caller side. The server on the other end might be Pipedream, a GitHub MCP server, a Stripe one, or something you wrote yourself over your own internal API.

You need MCP the moment your agent has to do anything outside its own context window: read a file, query a database, call an API, post to Slack. That is the starting point for basically every agent stack, which is why MCP client support showed up in the coding tools first.

Wiring one up on the client side is mostly a config file. Cursor reads a project-level .cursor/mcp.json (per Cursor's MCP docs, fetched 2026-07-15):

{
  "mcpServers": {
    "pipedream": {
      "url": "https://mcp.pipedream.net/v2"
    }
  }
}

Drop that in, and the agent can reach every connected account behind that server. The catch worth knowing up front: an MCP server hands your agent real write access, so the tool annotations that mark which actions are read versus write versus destructive matter a lot once you point an autonomous loop at it. Pipedream started attaching those annotations to all of its tools in its October 2025 MCP v2 release (per the Pipedream changelog, October 1 2025). Check for them before you let an agent run unattended.

A2A: the agent-to-agent wire

A2A is what MCP is not: a way for two independent agents to talk as peers. An orchestrator uses it to delegate a task to a specialist agent, stream back partial results, and collect a finished artifact, without either side exposing its tools or its internal state to the other. The A2A docs give the canonical example: a customer-service agent delegating an inquiry to a billing agent (per the A2A v1.0 docs).

Discovery is the clever part. Every A2A agent publishes an AgentCard, a public JSON document at a well-known path, so another agent can find it and learn how to authenticate without any hard-coded credentials. In the v1.0 spec that path is /.well-known/agent-card.json (older v0.x examples used /.well-known/agent.json, so watch for that if you copy an old tutorial). Here is the shape of a card, trimmed from the spec's own example (A2A v1.0 specification, section 4.6.1, fetched 2026-07-15):

{
  "name": "Research Assistant Agent",
  "description": "AI agent for academic research and fact-checking",
  "supportedInterfaces": [
    {
      "url": "https://research-agent.example.com/a2a/v1",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "0.3"
    }
  ],
  "capabilities": {
    "streaming": false,
    "pushNotifications": false
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "academic-research",
      "name": "Academic Research Assistant",
      "description": "Research assistance with citations and source verification",
      "tags": ["research", "citations", "academic"]
    }
  ]
}

Fetching one is exactly the boring HTTP call it looks like:

curl https://research-agent.example.com/.well-known/agent-card.json

Under that card, the transport is JSON-RPC 2.0 over HTTP, streaming rides Server-Sent Events, and authentication runs on OAuth 2.0. Cards can also be signed with JSON Web Signatures so a client can verify the card wasn't tampered with before it trusts a single skill on it (per the A2A v1.0 spec). You need this when you have two genuinely separate autonomous agents that must coordinate. If you have one agent and a pile of tools, you do not need A2A yet. MCP is enough, and adding an agent-to-agent protocol on top of a single agent is just ceremony.

Which tools in your stack support what

Here is where the tools our readers actually run stand today. Support in this category moves weekly, so treat the notes as a July 2026 snapshot and check the linked docs before you commit a build to it.

ToolMCP supportA2A supportHow to connect
n8nYesNot nativev2.22.0 shipped "Connect to MCP servers with less setup" (n8n release notes)
PipedreamYesNot nativeMCP v2 server at mcp.pipedream.net/v2, OAuth, 10,000+ tools across 3,000+ APIs (Pipedream changelog)
MakeYes, via Make MCP ServerAnnounced redesign, A2A not in docsMake MCP Server connects agents to 3,000+ apps (Make MCP)
CursorYesNot nativeProject .cursor/mcp.json (Cursor docs)
GitHub CopilotYesNot nativeMCP in the IDE via Copilot Chat (GitHub docs)

The pattern jumps out of the table: MCP is everywhere in the tool layer already, and native A2A is still thin on the ground in no-code land. That is not a knock. It matches the maturity curve. MCP is a year older and solves the problem every builder hits first.

If you want the fastest path to a working MCP-connected workflow, start with n8n, because the 2.22.0 setup flow removed most of the friction, or point any MCP client at Pipedream when you want thousands of pre-built tool connections behind a single OAuth URL instead of wiring each API yourself. On the A2A side, Make is the one to watch: its agent redesign is public and its MCP server already ships, but A2A support is not in Make's docs yet, so treat it as likely-to-follow rather than available today.

Four more protocols worth putting on your radar

None of these change what you build this month. All four are close enough that knowing the shape now beats getting surprised later.

WebMCP extends the stack to the browser. Google shipped an early preview in Chrome Canary in February 2026, built with Microsoft on a W3C track, so an agent can operate a web page through a declarative API instead of screen-scraping it (per the DEV Community writeup). Start tracking it when your agent's job is "go do this thing on a website that has no API."

OSI, the Open Semantic Interchange, adds the meaning layer. Snowflake launched it under an Apache 2.0 license in January 2026 to standardize what data means, not just its shape, which matters the moment an agent has to reason over a warehouse and not just query it (per DEV Community). Watch this if you are building data-platform agents.

x402 is the payments rail. Coinbase revived the long-dormant HTTP 402 status code so an agent can pay per call for an API or a piece of content in stablecoins, and OpenAI and Stripe's Agentic Commerce Protocol tackles the checkout side of the same problem (per DEV Community). Relevant the day your agent needs to buy access to something without a human in the loop.

Agent Cards, the discovery piece inside A2A, are the one to act on now rather than later. Publishing a /.well-known/agent-card.json for an agent you already run is cheap, and it is what makes that agent findable by any A2A client down the road. Self-hosting an agent that serves that endpoint means standing up a small always-on server, which is a one-box job on something like DigitalOcean if you don't already have somewhere to put it.

What we'd actually do

Pick your row and stop reading.

Solo operator with one agent and a handful of external tools: implement MCP, full stop. Point Pipedream or n8n at the APIs you care about and skip A2A entirely. You do not have the second agent that would make it worth anything.

Small team running two or more agents that coordinate: wire MCP into each agent for its own tool access, then use A2A for the handoffs between them. Run your orchestration in n8n or Make so the coordination logic lives somewhere you can see it, and publish an Agent Card for each agent so they can discover each other instead of carrying hard-coded endpoints.

Enterprise team writing a protocol strategy: this is not a choice between two standards, it is a two-layer stack, and you should plan both. MCP is already in production across the coding tools your developers use daily. A2A hit v1.0 with signed Agent Cards and 150-plus production organizations behind it (per DEV Community). Adopt MCP at the tool layer and A2A at the agent layer, and treat anyone selling you one as a replacement for the other as someone who read the July 14 headline and stopped there.