MCP, A2A or REST: when each agent protocol wins

Anyone who has wired two agents together in production knows the awkward moment: the first one works, the second one works too, and then you have to decide how they talk to each other. A piece published this week on Oracle Blogs organizes that problem into a simple, unglamorous matrix. It lays out three ways to communicate, MCP, A2A and plain REST, that do not compete for the same ground but win in different contexts.

The thesis is blunt: there is no universal protocol for agent systems, and forcing a single one onto every case is paid for in latency, maintenance or security. The value of the text is in separating three questions we tend to mix up.

MCP: the agent and its tools

MCP (Model Context Protocol), the standard Anthropic published so a model can call external tools, fits when the problem is 'this agent needs to read a file, query a database or call a function'. It is the layer between the model and the world. An MCP server exposes resources and tools under an explicit contract, and the client, whether Claude Code, Claude Desktop or another, discovers and calls them without the developer hardwiring each integration by hand. Its strength is standardization: once you have the server, any compatible client benefits from it.

A2A: agents that delegate to each other

When the problem stops being 'model calls a tool' and becomes 'one agent delegates to another agent', the article places the A2A protocol (Agent2Agent) there. Here both ends are autonomous: each has its own reasoning, its own state and its own goals. A2A defines how capabilities are advertised, how a task is handed off and how results are returned between agents that share neither memory nor owner. It is the scenario of real multi agent systems, where an orchestrator distributes work across services built by different teams.

Plain REST: when you do not need anything new

And then there is the option many dismiss as boring: a plain old REST API. If the interaction is deterministic, with no natural language involved and a stable contract, putting an agent protocol on top only adds layers. The analysis reminds us that REST still wins on low latency, high volume and idempotent operations. An endpoint that returns an account balance does not need dynamic discovery or capability negotiation: it needs to respond fast and always the same way.

Why it matters and for whom

The worth of the text is not in picking a winner, but in giving criteria. For anyone integrating agents, the useful question is not 'which protocol is trending?' but 'what kind of interaction am I facing?'. If it is a model asking for data or actions, MCP. If it is autonomous agents splitting tasks, A2A. If it is a predictable service call, REST. Most serious architectures end up combining all three, each in its own layer, and the costly mistake is stretching one outside its zone.

That mix has practical implications. Each protocol carries its own security model, its own way of authenticating and its own attack surface. A badly exposed MCP server hands out access to tools; a poorly designed A2A channel lets one agent command another without control. Treating all three with the same governance yardstick is where the problems creep in.

For teams already working with Claude, the message fits what we see every day: MCP solves the model to tool stretch very well, which is exactly where Anthropic positions it, and it does not try to be the communication bus between full agents. Seeing it as one piece of a set, and not as the answer to everything, saves redesigns.

At ElephantPink we have spent months building custom MCP servers, and Oracle's matrix puts words to an intuition we already applied: the right protocol depends on the conversation your components are having, not on which one showed up in the most recent press notes. A healthy reminder in a year when a new standard promising to unify everything appears every week.