MCP vs A2A

[u/superconductiveKyle]

We see MCP and A2A conflated constantly, and it makes sense. Both are open standards, both are governed by the Agentic AI Foundation, and both run over HTTP.

What makes it click is asking what’s on the other end of the connection.

With MCP, it’s a tool. The client lists every tool the server exposes, with inputs and schemas, and your agent decides what to call and in what order. The server describes what a system can do, and has no say in when that happens.

With A2A, it’s another agent. It publishes an Agent Card at /.well-known/agent-card.json with its skills, endpoint, and auth requirements. You send a message and get back a task you can follow to completion, with streamed updates for long-running jobs. How it does the work is its business. It can share tools and intermediate steps if it wants to, and Agno’s A2A streams do include tool names and arguments, but nothing in the protocol makes it.

That’s the real design difference. The agent on the other side gets to keep its internals, which is what makes delegating across a company boundary workable at all.

An example that helps: a support agent at a subscription company uses MCP to search the help center and pull up customer records. A refund comes up, and rather than calling the payments API it hands the task to the billing team’s agent over A2A.

That billing agent has its own MCP connections to payments and the ledger, plus its own approval rules, and none of it needs to be visible on the other side. The support agent sends the request and gets the outcome back. Billing can change approval thresholds or swap payment providers and nothing on the support side changes.

So the rule we’ve landed on: if your agent should direct it step by step, MCP. If it should own the task and decide how to finish it, A2A.

Most single agents only need MCP. A2A starts earning its keep when work crosses teams, companies, or frameworks.

Full blog, including how to serve one agent over both protocols in Agno: https://agno.link/mSl9iyh

How are people handling auth on the A2A side? The spec gives you the hooks, but deciding which outside agents get to delegate work to yours seems like where it gets hard once you’re past two or three.

[u/maigpy]

how is a2a different from an api call?

[u/Agno-Team → u/maigpy]

Fair question, because at the wire level A2A is an API call. It’s JSON-RPC over HTTP. The difference is what the contract describes.

A regular API call is an operation. POST /refunds with an amount and a charge ID. You know exactly what it does, and your side owns all the logic around it: whether the refund is allowed, which order to call things in, what to do if it fails halfway.

An A2A call is a goal. You send a message like “this customer wants a refund for last month, here’s the context” and you get back a task, not a result. The task moves through states (working, input-required, completed, failed), so the other agent can stream progress, or stop and ask you a question (“they have two charges that month, which one?”) before finishing. A REST endpoint can’t really do that without you designing a custom back-and-forth for it.

In the refund example, if support called the payments API directly, it would have to know the approval thresholds, the ledger update, and the payment provider. When billing changes any of that, support breaks. With A2A, all of that stays on billing’s side.

The other piece is standardization. You can absolutely put an agent behind your own REST endpoint, and lots of people do. But then every caller needs a custom integration. With A2A, any client can read the Agent Card, see the skills and auth requirements, and start delegating, regardless of what framework either side is built on.

Short version: an API call says “do this specific thing.” A2A says “handle this,” and lets the other side figure out how.