MCP versus A2A versus a plain API

Why it matters

Every agent design review reaches the same fork: the agent needs to reach a system, so do you call it directly, wrap it as an MCP server, or stand up an A2A peer? Candidates who have read the protocol sites answer "both" without saying when. The question tests whether you can size an integration to its consumers rather than to the fashion of the year. A 2026 survey found that most organisations have already built MCP integrations and rank them among the hardest things to move between providers, so the choice has a cost either way.

The idea

Three questions settle it: who consumes the integration, whether they need to discover it, and whose loop runs the work.

A plain API or SDK call

One application, one integration, full control. Your runtime imports the billing client, calls get_invoice, shapes the result and hands it to the model as a tool result. No protocol layer, no discovery, no extra auth: the service account is yours and the call is a function. This is the right default. It stops being right when a second AI client wants the same capability, because the wrapper, the result shaping and the permission checks now have to be copied.

MCP

Many AI clients need the same tools, discovery and one security model. The CRM team writes one server exposing search_contacts, get_account and a few resources, puts OAuth in front of it, and three assistants connect with one client each. The consumer is any host that speaks the protocol; discovery is the list methods; auth is a token per user validated per request; the loop still belongs to each host. The cost is a round trip per call, OAuth plumbing before the first useful request, and the definitions landing in every host's prompt.

A2A

Independent agents cooperate across a boundary. The consumer is another agent: it reads a card, sends a task, follows a lifecycle and keeps the artifacts, and it never sees inside. The remote side runs its own loop with its own model and tools. The cost is task state on both sides and a trust decision per peer; the benefit is that neither team exposes or coordinates its internals.

One product, all three

A support assistant for an online shop. It calls the shop's own order service through a plain SDK call: one consumer, one owner, lowest overhead. It reaches the company CRM through an MCP server, because the CRM team already serves three other AI clients and wants one place for authorisation and audit. And it hands delivery disputes to the logistics partner's agent over A2A, because that partner runs its own agent and will not share tools. The decision is made per integration, not per product.

The costs, named

Protocol overhead: a direct call is a function; MCP adds a JSON-RPC round trip and a definition in the prompt; A2A adds task state and streaming. Auth plumbing: a direct call reuses your service account; MCP wants OAuth per user on remote servers; A2A wants identity between organisations. Lock-in: a direct call ties you to one SDK, easy to swap; an MCP server ties the organisation to a catalogue of tools, descriptions and permission rules that hosts have been tuned against, which the survey shows is hard to move; A2A ties you to a partner's contract, the loosest coupling and the one you control least.

	Plain API or SDK call	MCP	A2A
Consumer	One application you own	Any host that speaks the protocol	Another agent, often another team's
Discovery	None; it is in your code	server/discover and the list methods	The agent card
Auth	Your service account	OAuth per user on remote servers; per-user authorisation	Declared on the card; identity between organisations
Overhead	A function call	A round trip per call plus definitions in every prompt	Task state, streaming, trust per peer
When	One consumer, one integration, full control	Several AI clients need the same tools under one security model	Independent agents cooperating across a boundary