Two Protocols, Two Different Problems

If you've been building AI agents in 2025 and 2026, you've probably run into both MCP and A2A. They sound similar. They're both open protocols. They both deal with how AI agents connect to things. But they solve completely different problems, and confusing them leads to poor architecture decisions.

MCP, the Model Context Protocol from Anthropic, handles how an agent accesses tools and data. A2A, the Agent-to-Agent protocol from Google, handles how one agent talks to another agent. That's the core distinction. Everything else follows from it.

This post is a practical breakdown of both protocols: what they actually do, where they overlap, and how to decide which one your system needs. Or whether it needs both.

What A2A Actually Is

Google released the Agent-to-Agent (A2A) protocol in April 2025 alongside a coalition of partners including Salesforce, SAP, Atlassian, and others. It's an open specification designed to let AI agents communicate with each other across different systems, frameworks, and vendors.

The core idea: as organizations start deploying multiple AI agents, those agents need to coordinate. A customer service agent might need to hand off work to a billing agent. A research agent might need to delegate a subtask to a specialized data analysis agent. Without a shared protocol, every integration becomes a custom bespoke contract.

A2A defines how agents discover each other, how they negotiate capabilities, and how they pass tasks back and forth. It uses standard HTTP and JSON, which means it's not tied to any specific framework or model provider. The spec covers agent discovery through an "Agent Card" (a JSON document that describes what an agent can do), task delegation, and streaming updates for long-running tasks.

The GitHub repository for the A2A spec is publicly available, and Google maintains reference implementations in Python and JavaScript. As of early 2026, frameworks including LangGraph and CrewAI have added support in various capacities.

What an Agent Card looks like

Every A2A-compatible agent publishes an Agent Card at a well-known URL. It's a JSON document that declares the agent's name, description, supported skills, authentication requirements, and endpoint. When another agent wants to delegate a task, it reads this card first to understand what the target agent can do and how to reach it.

This discovery mechanism is what makes A2A genuinely different from simply calling another service over HTTP. It creates a machine-readable contract that agents can reason about, not just a REST endpoint that developers have to read docs for.

What MCP Actually Is

The Model Context Protocol, introduced by Anthropic in late 2024, solves a different problem. It standardizes how an LLM-based agent connects to external tools, data sources, and resources. Think of it as a universal adapter between an AI model and the outside world.

Before MCP, every AI application that needed to access a database, run a web search, or read files had to build custom integrations. MCP creates a common interface so that tool providers write one MCP server, and any MCP-compatible agent can use it.

The protocol defines three main primitives: Resources (structured data an agent can read), Tools (functions the agent can call), and Prompts (pre-defined templates). An MCP server exposes these, and an MCP client (the agent) connects to consume them. Communication happens over stdio or HTTP with Server-Sent Events.

Genta has a detailed guide on how to build an MCP server if you want the implementation specifics. The short version: MCP is about agent-to-tool connectivity. It doesn't address how one agent coordinates with another agent.

Side-by-Side Comparison

Here's where they diverge clearly:

• Relationship type: MCP connects an agent to tools and data. A2A connects an agent to another agent.

• Directionality: MCP is a client-server model where the agent (client) pulls from or pushes to a tool (server). A2A is peer-to-peer, where both sides can be agents with their own reasoning capabilities.

• Statefulness: MCP interactions tend to be stateless function calls. A2A defines task lifecycle management, including task states like submitted, working, completed, and failed, with streaming updates for long-running work.

• Discovery: MCP servers are known in advance and configured by the developer. A2A includes a discovery mechanism via Agent Cards, so agents can find each other dynamically.

• Origin: MCP is an Anthropic spec now supported by a wide range of tools. A2A is a Google initiative with a broader industry coalition from the start.

They are not competitors. Google has been explicit that A2A and MCP are complementary. An agent might use MCP to access its tools and use A2A to delegate subtasks to peer agents. Most real production systems will end up needing both.

A Concrete Architecture Example

Imagine a company building an AI-powered procurement system. There's an orchestrator agent that handles purchase requests. That orchestrator needs to: query an ERP system for budget data, fetch supplier pricing from an external database, delegate contract review to a specialized legal agent, and send approval notifications via a messaging system.

The ERP query, pricing lookup, and notification steps are tool calls. The orchestrator uses MCP to connect to the relevant MCP servers for each. Standard tool invocations with predictable inputs and outputs.

The legal review step is different. The legal agent is a full AI agent with its own reasoning, its own context, and potentially its own tools. It runs as a separate service. The orchestrator uses A2A to delegate that task: it discovers the legal agent via its Agent Card, submits the contract review task, receives streaming status updates, and gets the result when the legal agent finishes.

In this system, MCP handles the edges (agent to external systems) and A2A handles internal coordination (agent to agent). Mixing them up would mean either trying to wrap a stateful reasoning agent as a simple tool call, which breaks down quickly, or over-engineering a peer-to-peer protocol for what should just be a database lookup.

When to Use A2A

A2A makes sense when the target of a delegation is genuinely another agent: something that has its own reasoning, state, and potentially its own tools. Specific signals:

• You're building a multi-agent system where different agents specialize in distinct domains, such as legal, finance, or technical analysis.

• You need long-running tasks with intermediate status updates, not fire-and-forget tool calls.

• Your agents span multiple organizations or teams and you can't share internal APIs directly.

• You want agents to discover capabilities dynamically rather than hardcoding every integration.

• You're building on frameworks like LangGraph or CrewAI that are adding native A2A support.

A2A is relatively new and the tooling is still maturing. If you're building a simple single-agent system, you almost certainly don't need it yet. The overhead of implementing the full task lifecycle and discovery mechanism isn't worth it for straightforward use cases.

When to Use MCP

MCP is the right choice when you need to connect an agent to external tools, APIs, data sources, or resources. The ecosystem here is already substantial. There are MCP servers for GitHub, Slack, PostgreSQL, Google Drive, web browsers, and dozens of other services, with more appearing regularly.

Use MCP when your agent needs to call external APIs or read and write to data systems. Use it when you want to reuse tool integrations across multiple agents without rebuilding them each time. Use it when your tool interactions are relatively stateless: query, get result, continue.

The official MCP documentation covers the full spec. The community server list is also a good way to see what's already built before writing your own integration from scratch.

The Trust Problem Neither Protocol Fully Solves

Here's something that's under-discussed: neither protocol fully resolves how agents from different providers discover and trust each other at scale. A2A's Agent Card is a step toward discovery, but trust and authentication across organizational boundaries is genuinely hard.

If Company A has a financial agent and Company B has a research agent, and they want those agents to collaborate, the A2A spec handles the communication format. But who decides which agents are allowed to delegate to which other agents? How do you enforce permissions when the delegating agent is an LLM that could potentially be manipulated through prompt injection? These are open problems that A2A doesn't fully resolve yet.

The Linux Foundation now hosts the A2A specification, which suggests longer-term governance ambitions. But the security and trust model for multi-organizational agent collaboration is still being figured out. Anyone building production systems that cross organizational trust boundaries should factor this in before assuming A2A handles it for them.

Practical Advice for Teams Building Now

A reasonable starting point for a new agentic system: default to MCP for tool connectivity, and evaluate A2A once you have more than one agent that needs non-trivial coordination.

Don't implement A2A prematurely. A single-agent system with good MCP tool coverage will outperform a multi-agent architecture with poor task decomposition every time. The complexity of managing agent-to-agent communication, task state, and failure modes is real. Add it when you actually need it, not because the spec exists.

When you do reach a point where multi-agent coordination is needed, A2A gives you a standard to build against instead of inventing a custom JSON protocol that only works in your codebase. That's its real value: reducing the surface area of bespoke integration contracts between agents that were never designed to talk to each other.

These architecture decisions compound fast. A system that starts with a clear separation between tool connectivity (MCP) and agent coordination (A2A) is much easier to extend than one where the two concerns are tangled. For teams building production-grade agentic systems where this matters from day one, the Genta team works embedded in client engineering teams and navigates exactly these protocol and architecture tradeoffs in real deployments.

Where This Is Heading

The emergence of both MCP and A2A within the same 12-month window signals something real: the ecosystem is trying to build standardized infrastructure for agentic systems before everyone ends up with incompatible proprietary silos. That's a healthy instinct.

In practice, expect more frameworks to bake in native support for both protocols. Expect cloud providers to offer managed A2A endpoints. Expect the security and governance layer to get more attention as agents start crossing organizational trust boundaries in production.

For now, the job is to understand what problem each protocol solves, and resist the temptation to use both everywhere just because both exist.