MCP had barely entered everyone’s vocabulary before ACP and A2A arrived to make the meeting notes look like airport codes. The protocols are related, but they do not compete at the same boundary.
An LLM can reason about a request, but it cannot fetch a customer record or update a ticket by telepathy. An agent combines the model with tools that search, execute code, query databases, or operate other systems. Multiple agents can then collaborate on a larger job.
MCP connects a model-facing client to tools #
The Model Context Protocol standardizes how an AI application discovers and calls external capabilities. It is the boundary between an agent’s model-facing runtime and tools or data sources.
“Giving the LLM context” can sound vague. Concretely, the MCP client invokes a server, the server obtains information or performs an operation, and the result becomes input to the model. MCP expands what one agent can do.
ACP and A2A connect agents to agents #
The Agent Communication Protocol targets a different relationship: communication between independently implemented agents. Those agents may use different frameworks or models. The protocol needs to support structured messages, longer-running work, and multi-turn exchange—not merely a function call and response.
| Concern | MCP | ACP |
|---|---|---|
| Purpose | Give an agent tools and context | Coordinate independent agents |
| Boundary | Client/runtime ↔ tool server | Agent ↔ agent |
| Typical exchange | Request and result | Multi-turn task conversation |
| Common use | Capability extension | Delegation and collaboration |
An ACP agent can still be exposed as an MCP tool when a one-shot call is sufficient. The ACP–MCP adapter existed for exactly this case. Protocol layers can compose; they do not need a cage match.
A2A also targets agent-to-agent interoperability. Its organizational history and architecture differ from ACP’s. Google donated A2A to the Linux Foundation on June 23, 2025, and the ecosystem was still moving quickly when the original article was written.
A multi-agent example #
Imagine a financial-services front desk. A coordinating agent interprets a customer’s request and delegates to specialist agents for onboarding, lending, or product questions. Each specialist uses its own tools to complete work.
Agent protocols let the coordinator speak to specialists even when one was built with LangGraph and another with CrewAI. MCP lets those specialists retain the same tool integrations when the underlying model changes or a model router selects a different provider.
The architectural test is simple: draw the arrow.
- If the arrow connects an agent runtime to a capability or data source, look at MCP.
- If it connects one autonomous agent to another, look at ACP or A2A.
- If the interaction is only one call, an adapter may let an agent present itself as a tool.
Standard protocols reduce coupling between models, frameworks, tools, and vendors. They do not remove the hard parts—identity, authorization, observability, failure recovery, and deciding whether an agent should be allowed to do the thing at all. Sadly, there is not yet a three-letter protocol for judgment.