MCP or A2A? How the Two Agent Protocols Fit Together

Part 2 of a four-part series. Part 1 gave an overview of both protocols and how they grew. This part is about design: what each protocol is for, where the boundary sits, and how to decide what your system needs.

The one-sentence version

MCP is how an agent reaches tools and data. A2A is how one agent works with another agent.

That sentence is easy to repeat and easy to misapply. Teams still ask "should we build an MCP server or an A2A agent?" as if they were choosing between two competing standards. They are not competing. Google said so in plain words when it announced A2A in April 2025: A2A "complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents." The rest of this article explains what that means in practice.

What MCP actually standardises

The Model Context Protocol defines three roles:

• Host — the AI application the person uses (a chat app, an IDE, an agent runtime).
• Client — a connector inside the host. The host creates one client per server.
• Server — a program that exposes capabilities to the model.

A server offers three kinds of primitives:

• Tools — functions the model can call, each with a JSON Schema for its arguments.
• Resources — data the application can read into context.
• Prompts — reusable templates.

Local servers usually run over stdio. Remote servers use Streamable HTTP, with JSON-RPC 2.0 messages.

The important design property is that, in the basic model, an MCP server is passive and transparent. It does not plan. It does not decide what to do next. The model in the host decides which tool to call, with which arguments, and what to make of the result. The server's job is to describe its tools well and return honest results.

That makes MCP the right fit when:

• you own data or an API and want any AI assistant to use it;
• each operation is a clear function: search, look up, check, create;
• the reasoning should happen in the user's assistant, not on your side.

What A2A actually standardises

Agent2Agent is built for a different relationship: two independent agents, possibly built by different vendors on different frameworks, that need to cooperate without sharing their internals. The specification calls this opaque execution: agents collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations.

Its core objects:

• Agent Card — a JSON document, normally at /.well-known/agent-card.json, describing the agent: name, skills, endpoints, supported interfaces, and how to authenticate.
• Task — a unit of work with a lifecycle (submitted, working, completed, failed, canceled, rejected, plus the interrupted states input-required and auth-required).
• Message — a turn from the client or the agent, made of Parts (text, file, or structured data).
• Artifact — an output the task produces.

Requests travel over JSON-RPC, HTTP+JSON (REST), or gRPC. Clients can wait for a reply, stream updates, or receive push notifications, depending on what the agent supports.

Where MCP's server is passive, an A2A agent is active. It receives a goal, works on it with its own model and its own tools, may ask for more input, and returns a result. The client does not see how the work was done. It only sees the task states and the output.

That makes A2A the right fit when:

• the other side has its own judgement: it plans, it checks, it says no;
• the work may take several steps or a long time;
• you want to delegate a goal, not call a function;
• the two sides are run by different organisations that will not share code or prompts.

The boundary, in one table

Four practical patterns

1. MCP only

You have a database or a service, and you want assistants to use it. Expose an MCP server, write good tool descriptions, and let the assistant's model do the reasoning. Most data providers should start here. It is the smallest surface and the easiest to test.

2. A2A only

You already have a capable agent, and other agents should hand work to it. You publish an Agent Card and accept tasks. Internally you may use anything: direct API calls, a workflow engine, or no tools at all.

3. A2A outward, MCP inward (the most common "both")

This is the layered picture at the top of this article. Each agent uses MCP to reach its own tools and data. Agents talk to each other over A2A. Neither agent needs to know what tools the other one has. The client agent only sees skills on an Agent Card and task results.

4. One capability, two front doors

A provider can expose the same capabilities through both protocols. An MCP client calls the tools directly and reasons on its own side. An A2A client sends a free-text request and lets the provider's agent do the reasoning, or sends a structured data part that maps to one exact tool call. One backend, two audiences: assistants that speak MCP, and agent frameworks that speak A2A.

A worked example using both

Take a traveller who asks their personal assistant: "Find me two days near a volcano in the first week of July."

1. MCP, inside the personal assistant. The assistant checks the traveller's calendar through a calendar MCP server and finds the free days.
2. A2A, between agents. The assistant does not know the region. It finds a regional travel agent through that agent's Agent Card and sends it a message: the dates, the group size, the interest.
3. MCP, inside the regional agent. The regional agent calls its own tools: a tour catalogue with live seats, place safety and volcano status, weather. The personal assistant never sees these tools. It sees a completed task with facts and links.
4. Human, at the edge. The assistant shows the options and the safety caveats, and asks the traveller whether to send a request. Only after an explicit yes, with the traveller's consent to share their contact details, does a request go out, and a human on the other side confirms or declines it.

Each protocol does one job. MCP keeps every agent connected to its own sources of truth. A2A lets two agents with different owners cooperate without exposing those sources to each other.

How to choose: five questions

1. Does the other side need to think? If it only answers well-defined calls, use MCP. If it needs to plan, verify, or refuse, it is an agent; consider A2A.
2. Who owns the reasoning, and who is accountable for it? If you want your own model to interpret your own data, an A2A agent lets you keep that responsibility. If you want the user's assistant to interpret it, MCP is enough.
3. Is the work one step or many? A single lookup is a tool call. A multi-step job that may pause for input fits a task lifecycle.
4. What do your callers already speak? Many assistants and IDEs have MCP clients. Many agent frameworks speak A2A. If both audiences matter, offer both front doors over one backend.
5. Where must a human confirm? Put the confirmation where the consequence is: before anything is sent to a real person or anything costs money. A2A has explicit task states for waiting on input. In MCP, the host and the tool design must enforce it.

Common mistakes

• Wrapping every tool as an agent. A weather lookup does not need a task lifecycle. Use MCP.
• Exposing an agent's internals as tools "for flexibility". If another organisation's agent should delegate goals to you, do not hand it your raw tools and prompts. Give it an Agent Card and tasks.
• Treating "the model said yes" as consent. Neither protocol turns a model's output into a person's agreement. Design the step where the person actually says yes.
• Promising what the backend does not do. If an action is a request that a human must confirm, the tool and skill descriptions should say so in plain words, so that no assistant tells a user it is done when it is not.

A live example of pattern 4

Vedar Kamchatka (vedarai.ru), a travel information portal for Kamchatka (not a travel agency), exposes the same capabilities through both doors: an open MCP server at https://vedarai.ru/api/mcp and an open A2A agent described at vedarai.ru/.well-known/agent-card.json. Over A2A, a free-text message is answered by the portal's own guide agent using the same tools; a structured data part {"tool", "arguments"} runs one exact tool call. It has six request types, each confirmed by a person. A request is not a booking, and no payment goes through Vedar.

Part 3 of this series looks at that setup in detail: the endpoints, the six request types, and the lifecycle of a request from an agent to a human. Connection details: vedarai.ru/mcp.

Sources

• Google Developers Blog, "Announcing the Agent2Agent Protocol (A2A)", 9 April 2025
• A2A Protocol Specification, latest released version 1.0.0
• Linux Foundation, A2A project launch, 23 June 2025
• Anthropic, "Introducing the Model Context Protocol", 25 November 2024
• MCP architecture overview
• MCP transports (specification 2026-07-28)

Prepared with AI for the Vedar Kamchatka project and checked against the sources above.