MCP, A2A or REST: which protocol fits your agents

Every few days the same question pops up in developer forums and on LinkedIn: MCP or A2A? Framed as if one protocol had to bury the other. A recent piece on Oracle Blogs takes that false choice apart with a simple, sensible idea: MCP, A2A and a classic REST API do not compete for the same job. The costly mistake is not picking the 'wrong' trendy protocol, but applying a correct one to the wrong communication pattern.

The article suggests thinking in terms of a communication matrix between agents. Instead of a ranking of winners, it sorts each option by a prior question: who talks to whom, and what for. Change the question and the whole architecture decision changes.

MCP: the model talks to its tools

MCP (Model Context Protocol), the open standard Anthropic published in late 2024, covers a vertical axis: how a model reaches tools, data and context. An MCP server exposes functions, resources and prompts that the model can call in a structured way, without every integration being a bespoke patch. It is, in practice, the plumbing between an LLM and the outside world.

It shines when the problem reads like this: this agent needs to read this CRM, query this database or run this specific action. MCP standardizes that access so the model does not depend on different glue for each service. Its natural domain is the relationship between an agent and its capabilities, not the conversation between agents.

A2A: agents that negotiate as peers

A2A (Agent2Agent) goes after the horizontal axis: coordination between autonomous agents that share neither code nor the same vendor. Each agent publishes a description of what it can do, an 'Agent Card', and other agents discover it, agree on a task and collaborate without a central orchestrator running everything.

According to Oracle's analysis, A2A wins when there are several specialized agents, possibly from different teams or even different companies, that must understand each other. Picture a logistics agent negotiating with the inventory agent of another system. There, handing tools to a model is not enough: you need a common language so two independent pieces can talk without knowing each other beforehand.

REST: when you do not need an agent

The third option is the least flashy and, Oracle argues, the most underrated: a plain old REST API. If the interaction is deterministic, the contract is well defined and there is nothing to reason about or negotiate, putting an agent in the middle only adds latency, cost and new points of failure. An HTTP call that returns a predictable JSON needs no agent semantics or dynamic discovery. It works, it is cheap and it has been doing so for decades.

Why fit matters

The underlying thesis is about architecture, not trends. The three protocols can coexist in the same system: REST for deterministic services, MCP to give each agent its tools and A2A so those agents coordinate with one another. Seen this way, the useful question stops being 'which protocol is best' and becomes 'what kind of communication am I looking at'.

Who it matters for: any team designing systems with one or several agents and unsure whether to build new infrastructure or reuse what it already has. The matrix helps avoid overengineering. Not every problem with an LLM calls for a swarm of agents talking over A2A; many are solved with a single agent, a couple of MCP servers and some unglamorous REST call.

At ElephantPink we have spent months building MCP integrations for clients, and the read matches what we see in production. Most projects that start by asking for 'a multi-agent system' end up solved with a single agent well connected over MCP and, yes, some boring REST API nobody wants to touch. A2A is powerful and has a future, but today it earns its place mostly when there are real organizational boundaries between the agents. Choosing by the communication pattern, not by the headline of the month, is still the most profitable advice.