Skip to content
Welzin
Talk to us
← All posts

WOSS

MCP vs A2A: How AI Agents Talk to Tools - and to Each Other

Aman Mundra · 2026-07-04

TL;DR - MCP and A2A are the two open protocols that make multi-agent systems interoperable - and they are complementary, not competing. MCP (Model Context Protocol) defines how an agent connects to tools and data. A2A (Agent-to-Agent) defines how agents discover and collaborate with each other. Both now live under the Linux Foundation. Here's how each works, with examples, and how to use them together.

"Should I use MCP or A2A?" is the wrong question. It's like asking whether to use HTTP or DNS. You use both, for different jobs.

Once you see the split clearly, the entire agentic stack snaps into focus.

What problem does each protocol solve?

An agent needs to do two fundamentally different things:

  1. Reach outward to tools - query a database, call an API, read a file, run code. That's a vertical connection from an agent down to a capability.
  2. Coordinate with other agents - hand off a task, stream a partial result, ask a specialist agent for help. That's a horizontal connection between peers.

MCP owns the vertical. A2A owns the horizontal.

text
        Agent  <──── A2A ────>  Agent      (peers coordinating)
          │                       │
         MCP                     MCP        (each reaching down to tools)
          │                       │
   [ tools · data · APIs ]  [ tools · data ]

Confuse them and you'll build something brittle. Separate them and you get a clean, interoperable architecture.

What is MCP (Model Context Protocol)?

MCP is the universal standard for connecting AI models to tools, data, and applications - often described as "the USB-C port for AI." Originally a client-server protocol for LLM tool use, its specification (latest dated November 25, 2025) has grown to support distributed execution, stateless transport, and a security framework.

Adoption is enormous: by March 2026, MCP reached 97 million monthly SDK downloads. It was donated to the Linux Foundation's Agentic AI Foundation (AAIF) in December 2025.

A minimal MCP server exposing one tool looks like this:

python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-tools")

@mcp.tool()
def get_forecast(city: str) -> str:
    """Return the weather forecast for a city."""
    # ...call your weather API...
    return f"Sunny, 31°C in {city}"

if __name__ == "__main__":
    mcp.run()   # any MCP-compatible agent can now use get_forecast

Write it once; every MCP-aware agent - from any vendor - can call it. That's the point. The same server can be consumed by an agent built on any framework and any model provider, because the contract is the protocol, not the SDK. That single property is what turned MCP from a nice idea into infrastructure: those 97 million monthly downloads are the ecosystem voting for "write the tool once" over "reintegrate for every framework."

What is A2A (Agent-to-Agent)?

A2A defines how agents discover each other and interact as peers - sharing tasks, streaming results, and coordinating work across organizational boundaries. It reached v1.0 in April 2026, is supported by 150+ organizations, was donated by Google to the Linux Foundation, and is integrated into the AWS, Microsoft, and Google cloud platforms - making it the de facto standard for inter-agent communication in enterprises.

The core primitive is the Agent Card - a manifest that advertises what an agent can do, so other agents can find and call it:

json
{
  "name": "invoice-reconciler",
  "description": "Matches invoices to payments and flags discrepancies",
  "capabilities": ["reconcile", "flag-anomaly"],
  "endpoint": "https://agents.example.com/a2a/invoice-reconciler",
  "streaming": true
}

One agent reads another's card, sends it a task, and streams back the result - no bespoke integration, no shared codebase. Because the card is discoverable and the interaction is standardized, an agent can call a peer it has never seen before - which is exactly what you need when agents span teams, vendors, or company boundaries. That cross-boundary reach is why A2A landed in the AWS, Microsoft, and Google cloud platforms within its first year and why 150+ organizations rallied behind the v1.0 spec.

How do MCP and A2A work together? (a worked example)

The two protocols are easiest to understand when you watch them run side by side. Imagine an expense-reporting workflow with three agents:

  • an Orchestrator agent that owns the user's request,
  • a Receipt-Reader agent that extracts line items from uploaded images, and
  • an Invoice-Reconciler agent (the one whose Agent Card we saw above) that matches those line items against payment records.

Here is how a single "reconcile last month's expenses" request flows through the stack:

  1. The Orchestrator reads the Receipt-Reader's Agent Card and sends it a task over A2A: "parse these 40 receipt images." This is a sideways, agent-to-agent hop.
  2. Internally, the Receipt-Reader reaches down over MCP to an OCR tool and a storage bucket - tools it owns - to do the actual extraction. The Orchestrator never sees those tools; it only sees the result streamed back over A2A.
  3. The Orchestrator then sends the extracted line items to the Invoice-Reconciler over A2A.
  4. The Invoice-Reconciler reaches down over MCP to the accounting database, runs its matching logic, and streams flagged discrepancies back up.
  5. The Orchestrator composes the final report for the user.
text
   User
    │
 Orchestrator ──A2A──> Receipt-Reader ──MCP──> [ OCR · storage ]
    │
    └────────A2A──────> Invoice-Reconciler ──MCP──> [ accounting DB ]

Notice the pattern: every arrow between agents is A2A; every arrow from an agent to a capability is MCP. No agent hard-codes another agent's tools - the Orchestrator doesn't know or care which OCR engine the Receipt-Reader uses. You could swap the Receipt-Reader for a different vendor's agent tomorrow, and as long as its Agent Card advertises the same capability, nothing else changes. That substitutability is the whole payoff of keeping the two protocols separate.

When do you use MCP vs A2A?

You want an agent to…UseWhy
Query a database or call an APIMCPAgent-to-tool connection
Read files, run code, use a serviceMCPAgent-to-tool connection
Expose an internal capability so any agent can use itMCPWrap it as a tool once, reuse everywhere
Hand a subtask to a specialist agentA2AAgent-to-agent coordination
Discover what other agents can doA2APeer discovery via Agent Cards
Stream a long-running result back to a callerA2ATask/streaming is a peer interaction
Coordinate agents across org or team boundariesA2AWorks without a shared codebase
Build a single agent with many toolsMCPIt's a tool-integration problem
Build a multi-agent workflowBothA2A between agents, MCP under each

The rule of thumb: MCP goes down, A2A goes sideways.

How do they fit into the bigger picture?

Both protocols sit under Linux Foundation governance - MCP inside the Agentic AI Foundation (AAIF), A2A in the broader LF agentic ecosystem - which is exactly why you can bet on them. They're neutral, multi-vendor, and not going to be yanked behind a paywall. (For the full picture of what AAIF governs and why the industry backed it so fast, see the AAIF explainer.)

In a cloud-native deployment, this maps cleanly: run your agents on Kubernetes (via a runtime like kagent, which speaks MCP natively), let each agent reach its tools over MCP, and let agents coordinate over A2A. That's the interoperable, standards-based agentic stack - no lock-in at any layer. This is the concrete CNCF↔AAIF bridge: CNCF gives you the runtime to run agents; AAIF gives you the standards for how they connect and behave.

Frequently asked

What is the difference between MCP and A2A?

MCP (Model Context Protocol) defines how an AI agent connects to tools, data, and applications - the agent-to-tool link. A2A (Agent-to-Agent) defines how agents discover and coordinate with each other as peers - the agent-to-agent link. They are complementary: MCP goes down to tools, A2A goes sideways between agents.

Are MCP and A2A competitors?

No. They solve different problems and are designed to work together. A multi-agent system typically uses A2A for agents to coordinate and MCP for each agent to reach its own tools and data. Both are governed under the Linux Foundation.

Which should I use for my agent project?

Use MCP if you're connecting a single agent to tools, data, or APIs. Use A2A if you need multiple agents to discover and collaborate with each other. Most production multi-agent systems use both - A2A between agents, MCP beneath each one.

Do I need A2A if I only have one agent?

No. If you're building a single agent that connects to tools, databases, and APIs, MCP alone is enough - A2A only earns its place once you have multiple agents that need to discover and delegate to each other. Start with MCP, and reach for A2A when you split one agent into a coordinated team.

Who governs MCP and A2A, and can they be locked behind a paywall?

Both are open standards under the Linux Foundation - MCP within the Agentic AI Foundation (AAIF), A2A in the broader LF agentic ecosystem - with multi-vendor governance and backing from AWS, Google, Microsoft, Anthropic, OpenAI and others. That neutral governance is precisely what makes them safe to build on: no single vendor can pull them behind a paywall.

Written by Aman Mundra - founder of Welzin and the Welzin Open Source Software (WOSS), which contributes upstream to kagent and the open agentic-AI ecosystem.

← All postsTalk to a senior engineer →