MCP vs A2A: Tools for Agents vs Agents Talking to Agents

MCP and A2A are not competing standards; they cover different connections. MCP, the Model Context Protocol, is how an AI application reaches tools and data: it lists what a server offers and calls it, one operation at a time. A2A, the Agent2Agent protocol, is how one agent hands work to another agent: it finds out what the other agent can do, sends it a request, and follows the task until it finishes, without ever seeing how the other agent does it. The A2A project’s own page on A2A and MCP↗ (opens in a new tab) sums it up as agent-to-tool versus agent-to-agent, and calls the two complementary. For MCP itself, see what MCP is; for what counts as an agent, see AI agent.

The short version

• What sits on the other end: with MCP, a tool server that does what it is told; with A2A, another agent that decides how to do the job.
• Unit of work: MCP has a tool call that returns a result; A2A has a task that moves through states and can take minutes or days.
• Discovery: an MCP client asks a server for tools/list; an A2A client reads the remote agent’s Agent Card.
• Visibility: an MCP tool’s input and output are fully described by a schema; an A2A agent is deliberately opaque, sharing results but not its reasoning or tools.
• Where you meet them: MCP is built into the assistants many people already use; A2A matters when you run or buy agents that must work with agents from other vendors.

MCP: one agent, many tools

An MCP server publishes tools, each with a name, a description and an input schema. The client lists them, the model picks one, and the client calls it. The MCP tools specification↗ (opens in a new tab) calls tools model-controlled: the model decides when to use them, and there should always be a person able to deny a call. In the current revision, 2026-07-28, the protocol is stateless, so each request stands on its own and carries its protocol version with it.

The important word is tool. A tool does a defined thing with defined inputs and returns. It does not negotiate, ask clarifying questions of its own accord, or decide to do the job differently. When an assistant calls fenbs_create_item, the result is a task on a board or a refusal that explains why, nothing more open-ended than that. How MCP relates to the layers around it is covered in MCP vs API and MCP vs function calling.

A2A: agents that delegate to agents

A2A starts from a different situation: you have an agent, someone else has an agent, and neither of you wants to expose the internals. The A2A specification↗ (opens in a new tab) is built around a few objects.

• Agent Card: a JSON document describing the agent: its name and provider, its endpoint, the features it supports, how to authenticate and the skills it offers.
• Task: the unit of work, with an identifier and a status that moves through states such as submitted, working, input required, completed, failed, cancelled and rejected.
• Message: a turn in the conversation, from the user side or the agent side, made of parts.
• Part and Artifact: parts carry text, files or structured data; artifacts are the outputs a task produces.

Agents find each other through that card. The A2A guide to agent discovery↗ (opens in a new tab) recommends publishing it at /.well-known/agent-card.json on the agent’s domain, so a client can fetch it before sending any work.

GET https://agent.example.com/.well-known/agent-card.json
<- name, endpoint, skills, auth schemes, streaming: true

SendMessage { "Find three suppliers for part 4471 under our spend limit" }
<- task: working
<- task: input-required  ("Which delivery region?")
SendMessage { "UK only" }
<- task: completed, artifact: supplier shortlist

The specification defines three standard bindings, JSON-RPC, gRPC and HTTP with JSON, and three ways to follow a long task: poll it, stream updates, or have the remote agent send a push notification to a webhook. Its guiding idea is that agents collaborate through declared capabilities and exchanged results, without sharing their internal thoughts, plans or tool implementations.

The difference that matters: who decides

With MCP, the calling agent makes every decision and the server executes. With A2A, the calling agent decides what it wants, and the remote agent decides how to get it, possibly asking questions, possibly calling its own tools over MCP along the way. The A2A documentation puts it as MCP deepening a single agent and A2A connecting agents across a boundary.

That has consequences you should think about before reaching for A2A. A tool call is easy to review: you can see exactly what went in and what came out. A delegated task is harder, because the work happens inside someone else’s agent. You get the result and whatever artifacts it chooses to return, not a trace of what it did. That is the point of the design, and it is also why delegation to an outside agent needs the same care as handing work to an outside contractor.

Where A2A stands today

A2A was created by Google and announced in April 2025. In June 2025 the Linux Foundation launched the Agent2Agent project↗ (opens in a new tab) to hold it under neutral, vendor-independent governance. The specification has since reached version 1.0.

In August 2026 it moved again within the Linux Foundation, becoming a project of the Agentic AI Foundation, the same foundation that hosts MCP and AGENTS.md. The A2A announcement↗ (opens in a new tab) describes it as a growth-stage project there and says more than 150 organisations back it. Backing is not the same as production use, and most of what teams connect to an assistant today is still tools, which means MCP.

When you need which

• Your assistant needs to read or change something, such as a board, a repository or a database: MCP.
• You are exposing your product to assistants built by others: an MCP server.
• Your agent needs to hand a whole job to an agent run by another team or company, which will decide how to do it and may take a while: A2A.
• You run several agents of your own on one framework: you may need neither between them, since the framework already passes work around; add A2A when an agent outside it has to join.

A shared record, whichever protocol you use

Neither protocol gives a person a place to see what the agents agreed and who did what. A2A task states live inside the exchange between two agents; MCP tool calls live in each client’s logs. If people need to follow the work, it helps to put it somewhere they can read.

fenbs speaks MCP, not A2A. Assistants from different vendors, such as Claude, ChatGPT and Cursor, can each be members of the same board with a role of their own, and every change is recorded with who made it. An assistant can take the next task a person has pre-approved with fenbs_next_approved_task, which holds it for a few hours, or hand it back with fenbs_release_task and a reason, so it goes to Next Up for someone else. That is not agents talking to each other; it is agents and people working from the same list.