MCP vs A2A vs HTTP APIs — what's actually different, and when each one wins

A team we talked to recently had wrapped their internal pricing service in an MCP server. Not because a model needed to call it — because MCP was the new thing and the service felt "AI-adjacent." The only consumer was another backend service that would have been happier with a plain HTTP call. They'd added a protocol layer, a server process, and a discovery mechanism to solve a problem they didn't have.

The opposite happens just as often: a team building an agent that needs to read a customer's calendar hand-rolls the tool schema, the auth, and the invocation glue into the model's prompt, when MCP exists precisely to standardise that.

MCP, A2A and HTTP APIs are not competitors fighting over the same job. They sit at different layers, have different callers, and answer different questions. Confusing them is how you over-engineer the simple cases and under-engineer the hard ones. This is a map of what each one is actually for.

HTTP APIs — the substrate everything else runs on

An HTTP API is the oldest and most general of the three: a client sends a request, a server sends a response, and a human designed the contract in between. REST, GraphQL, gRPC over HTTP/2 — the flavours differ, but the shape is the same.

The defining characteristics:

• The caller is a program a human wrote. A frontend, a mobile app, a backend service, a cron job. Something deterministic, calling an endpoint someone deliberately coded against.
• The contract is designed by humans, ahead of time. Someone decided that POST /orders takes this JSON and returns that JSON. The caller is expected to know the contract in advance — usually from docs or an OpenAPI spec.
• Discovery is out-of-band. You read the documentation, you get an API key, you write code. There's no runtime "what can you do?" handshake; the answer lives in a spec or a Postman collection.

HTTP APIs are the substrate. "MCP replaces APIs" is wrong in the same way "containers replace servers" is wrong — the API is still there underneath. What changes is who's calling it and how they found out it exists.

MCP — a standard way to hand tools to a model

The Model Context Protocol solves a specific, recent problem: a model host needs to discover and call tools without someone hand-coding the glue for every integration.

Before MCP, every "give the LLM a tool" integration was bespoke. You wrote a function schema in whatever format your framework wanted, wired the invocation into your agent loop, handled the auth yourself, and did it all again for the next tool and the next framework. MCP standardises that surface. An MCP server exposes three things to a model host:

• Tools — functions the model can invoke (send an email, query the database, run a search).
• Resources — data the model can read into context (a file, a table, a document).
• Prompts — reusable prompt templates the server offers up.

The crucial difference from an HTTP API is the caller and the discovery model. The caller is a model host — Claude Desktop, an IDE assistant, an agent runtime — not a program a human wrote to hit a specific endpoint. And discovery happens at runtime: the host connects to the server, asks "what tools do you have?", and gets back machine-readable schemas it can hand to the model right now. Nobody wrote code against a specific tool ahead of time. That's the whole point — the model decides what to call based on descriptions it discovered a moment ago.

Underneath, an MCP tool almost always wraps something ordinary. The "send an email" tool calls your email provider's HTTP API. The "query the database" tool runs SQL. MCP isn't replacing those; it's giving the model a uniform, discoverable way to reach them.

A2A — agents delegating to other agents

Agent-to-Agent protocols answer the newest question: how do two autonomous agents, possibly built by different teams or vendors, negotiate and delegate work to each other?

An HTTP API assumes a known contract. MCP assumes one model host reaching down to tools. A2A assumes something messier: a peer relationship between agents that each have their own goals, capabilities, and reasoning loop. One agent needs a task done, another agent can do it, and they have to figure out the handoff themselves.

That changes the primitives. A2A protocols concern themselves with:

• Capability advertisement. An agent publishes what it can do — often as an "agent card" — so other agents can decide whether to delegate to it.
• Task negotiation and delegation. Not a single request/response, but a task with a lifecycle: submitted, working, needs-input, completed. The delegating agent hands over a goal, not a precisely-specified function call.
• Long-running, stateful collaboration. Tasks can take minutes or hours, stream partial results, and require multiple turns. The interaction is a conversation between peers, not a stateless call.

The caller here is another agent, and neither side fully controls the contract — they negotiate it. That's the defining break from the other two protocols. HTTP and MCP both have a clear authority: the API owner, the tool provider. A2A is peer-to-peer by design.

The comparison, dimension by dimension

Line the three up against the questions that actually matter and the boundaries get sharp.

Who's the caller? HTTP API: a program a human wrote. MCP: a model host acting on a model's decisions. A2A: another autonomous agent.

Who designs the contract? HTTP API: the server owner, up front. MCP: the tool provider, exposed as runtime-discoverable schemas. A2A: negotiated between peers — no single owner.

How is discovery done? HTTP API: out-of-band, via docs and specs read by developers. MCP: in-band at runtime — the host asks the server what it offers. A2A: capability advertisement — agents publish cards other agents can read.

How stateful is it? HTTP API: usually stateless per request. MCP: session-oriented — a connection with discovered capabilities. A2A: long-running, stateful tasks with a lifecycle.

What's the auth model? HTTP API: keys, OAuth, mTLS between known parties. MCP: the host holds credentials and mediates the model's access to the server. A2A: agent identity and delegated authority — proving one agent is allowed to act on behalf of a user or another agent.

The pattern in that table: each protocol adds autonomy to the caller. HTTP calls come from deterministic code. MCP calls come from a model choosing among discovered tools. A2A calls come from an agent deciding to delegate. The less you can predict the caller's behaviour ahead of time, the higher up the stack you are.

They compose — that's the point

None of this is a replacement ladder. In a real system all three run at once, stacked.

Picture an agent that plans a business trip. It's an A2A participant — your travel-planning agent delegates "find and hold a flight" to a specialised booking agent from another vendor. That booking agent, to do its job, uses MCP tools: flight search, calendar, payment. Each of those MCP tools, when invoked, makes an ordinary HTTP API call to an airline, a calendar provider, a payment gateway.

A2A on top, MCP in the middle, HTTP at the bottom. Peel any layer back and the one below is doing the concrete work. If your problem lives entirely at the bottom layer, you don't need the top two — adding them is the over-engineering we opened with.

When each one wins

Reach for an HTTP API when the caller is code you or a partner wrote, the contract is knowable in advance, and there's no model in the loop deciding what to call. Service-to-service, frontend-to-backend, partner integrations. This is still the overwhelming majority of system communication, and it should be — if a plain HTTP call does the job, it's the right answer.

Reach for MCP when a model host needs your capability and you want it discovered and invoked in a standard way rather than hand-wired into one framework. Exposing internal tools to an assistant, letting an agent read your documents, giving a coding agent access to your build system. The tell: the consumer is an LLM deciding at runtime what to call, and you'd otherwise be writing bespoke tool-wiring per host.

Reach for A2A when you have genuinely autonomous agents — often across organisational or vendor boundaries — that need to delegate open-ended tasks to each other and coordinate over time. The tell: no single party owns the contract, tasks are long-running, and both sides are reasoning agents rather than one being a fixed tool.

The mistakes that cost the most

Wrapping everything in MCP because it's new. If the only caller is another service, MCP is pure overhead — a server process, a session, a discovery step, to replace an HTTP call you already understand. Add MCP when a model is the consumer, not before.

Hand-rolling what MCP standardises. The inverse. If you're pasting bespoke tool schemas into prompts and re-implementing auth glue for every assistant you integrate with, you're rebuilding MCP badly. Use the standard.

Reaching for A2A when you just have tool calls. A2A is for peer agents negotiating tasks. If you have one agent calling functions, that's MCP (or plain tool-calling), not A2A. The negotiation, lifecycle, and identity machinery of A2A is dead weight when there's a clear caller and a fixed tool.

Ignoring auth boundaries as you go up the stack. Each layer changes who's trusted with what. An MCP host mediates a model's access to a tool — the model shouldn't hold raw credentials. An A2A delegation carries authority from one agent to another on a user's behalf; get that wrong and an agent acts with permissions it was never granted. The higher up you go, the more the auth model is the hard part, not an afterthought.

Treating them as an either/or. The most expensive mistake is architectural: deciding your system is "an MCP system" or "an A2A system." It's almost always all three at different layers. Design each interaction for what it is.

TL;DR

HTTP APIs are for programs calling servers over a human-designed contract — the substrate everything else runs on. MCP is for handing tools and resources to a model host in a standard, runtime-discoverable way. A2A is for autonomous agents negotiating and delegating open-ended tasks to each other.

They compose rather than compete: an A2A agent calls MCP tools that wrap HTTP APIs. Pick by asking who the caller is — deterministic code wants HTTP, a model choosing a tool wants MCP, an agent delegating to a peer wants A2A. Don't add a layer you don't have a caller for, and don't hand-roll a layer that already has a standard.

If you're deciding how your systems should talk to models and to each other, let's talk.