If You Already Have MCP, Do You Actually Need A2A?

There's a genuine debate happening right now among people building agentic systems, and it's worth having honestly rather than resolving it with a hot take. MCP (Model Context Protocol) gives an agent a standardized way to discover and call tools. A2A (Agent-to-Agent protocol) gives an agent a standardized way to discover and communicate with other agents. On paper these sound complementary — tools versus peers. In practice, a lot of things that get built as "agent-to-agent communication" could plausibly be modeled as one agent calling another agent as if it were a tool, through MCP, and never touching a second protocol at all.

So: if MCP is already in place, is A2A solving a real, separate problem, or is it solving a problem MCP already covers, dressed up in different vocabulary? Reasonable, well-informed people currently disagree. Here's the actual shape of the disagreement.

What each protocol was built to do

MCP's model is fundamentally client-to-server: an agent (the client) connects to an MCP server, discovers what tools/resources it exposes, and invokes them. The server doesn't have its own goals, doesn't maintain a multi-turn negotiation with the agent, and isn't itself reasoning about what to do — it exposes capabilities and executes what it's asked to execute. It's a well-defined, mostly stateless interaction: discover, call, get a result.

A2A's model is peer-to-peer between autonomous entities: one agent can discover another agent's "card" (its declared capabilities), send it a task, and — this is the meaningful difference — the receiving agent might not respond immediately or atomically. It might work on the task over an extended period, ask clarifying questions, report partial progress, or decide on its own how to accomplish what it was asked, using its own tools and judgment along the way. It's designed for cases where the other side is a genuine second locus of autonomy, not just a capability being invoked.

flowchart LR
    subgraph MCPModel["MCP: Client calls Server"]
        A1["Agent"] -- "discover + invoke" --> S1["MCP Server\n(exposes tools, no independent goals)"]
    end
    subgraph A2AModel["A2A: Peer negotiates with Peer"]
        A2["Agent A"] <-- "task, negotiate,\nreport progress" --> A3["Agent B\n(own goals, own reasoning)"]
    end

The case for "you probably don't need A2A"

A large share of what gets described as "agent-to-agent" in practice is really just one agent invoking a capability that happens to be implemented by another agent internally. If Agent A asks Agent B to "summarize this document" and gets a summary back, that's structurally identical to Agent A calling a tool that happens to be backed by an LLM — Agent A doesn't need to know or care that a second agent, rather than a plain function, produced the answer. Wrapping Agent B behind an MCP server, with "summarize" exposed as a tool, gets you the same outcome with one protocol instead of two, one discovery mechanism instead of two, and one auth model instead of two.

The people skeptical of A2A's necessity make a fairly sharp version of this argument: most "multi-agent systems" are actually single-agent-with-many-tools systems wearing fancier terminology, and treating every sub-agent as a formal peer requiring its own negotiation protocol adds coordination overhead — more moving parts to secure, monitor, and debug — for a problem that a tool call already solves. Every additional protocol is additional attack surface, additional places identity and authorization have to be gotten right, and additional operational complexity, and that cost should have to earn its place, not be added by default because the industry has decided agents talking to agents sounds more sophisticated than agents calling tools.

The case for "A2A solves something MCP genuinely doesn't"

The counterargument isn't that this critique is wrong about some cases — it's that it doesn't hold once the other side is genuinely autonomous rather than just a wrapped capability. MCP's request/response shape assumes the server is stateless from one call to the next and doesn't have its own ongoing objectives; it's built for "call this function, get this result," not "delegate this multi-step goal to something that will pursue it over time, possibly asking you follow-up questions along the way, possibly deciding on a completely different approach than the one you expected." Forcing that kind of interaction through a tool-call interface tends to mean building your own ad hoc state machine and polling convention on top of MCP anyway — at which point you've reinvented a chunk of what A2A already standardizes, just without the interoperability benefit of it being a shared standard other agents already speak.

There's also an organizational-boundary argument that's harder to wave away: MCP servers are typically things you stand up and control, exposing your tools. A2A is aimed more squarely at agents built by different teams, or different companies entirely, that need to discover and negotiate with each other without either side having to know the other's internal implementation — closer to how two companies' systems integrate via a shared API contract than how one internal service calls another. If your agents genuinely need to interact with agents you don't operate and didn't design, "expose an MCP server and hope the other party wraps you as a tool" is a weaker fit than a protocol actually designed for cross-boundary agent negotiation.

flowchart TD
    Q1{"Is the other side stateless,\nreally just executing what it's told?"}
    Q1 -->|Yes| MCP1["Model it as an MCP tool"]
    Q1 -->|No - has its own goals,\nmulti-turn, may push back or negotiate| Q2{"Same team/org,\nsame trust boundary?"}
    Q2 -->|Yes| Judgment["Debatable - either can work;\nteams disagree here"]
    Q2 -->|No - different org,\ndifferent trust boundary| A2A1["A2A fits the boundary better"]

Where this is genuinely unsettled

Even people building production agent systems right now don't fully agree on where the line sits, and it's worth naming the specific points of disagreement rather than pretending there's a clean resolution:

Whether "has its own goals and can take a while" is really a protocol-level distinction, or whether it's just a slower, chattier tool call that MCP could represent with async/streaming primitives, given enough extensions to the spec. Whether cross-organizational agent discovery is a real, near-term need for most teams, or a problem being solved in advance of the use cases that would actually require it. And whether running two protocols in the same system is a manageable, occasionally-necessary cost, or a sign that one of the abstractions is redundant and the ecosystem hasn't converged yet on which one wins.

Reasonable, technically serious people land in different places on all three of these, often based on what kind of system they're actually building — an internal agent orchestrating internal tools is a very different situation than a platform meant to let external, independently-built agents interact with each other.

Where does this leave a team deciding today?

Probably closer to "model it as an MCP tool call until you have a concrete reason not to" than "adopt both protocols by default" — the org-boundary and genuine-autonomy cases for A2A are real, but they're also the minority of what most teams are actually building right now, and the coordination cost of running two protocols is not hypothetical. But that's a leaning, not a settled answer, and it's worth being honest that this is still being worked out in practice rather than in the spec documents.

What's your read on this? If you're building agent systems today, has A2A solved a problem MCP genuinely couldn't, or has it mostly added a second protocol to a system that would have worked fine as an MCP tool graph? The honest answer probably depends on details this article can't see from the outside — worth comparing notes rather than treating either position as settled.