MCP, A2A and AI Protocols: What Talks to What
AI systems are acquiring a lot of protocols. The names sound similar, but they solve different problems.
The useful question is not “which protocol should I use?” It is “which boundary am I trying to standardise?”
MCP: connect an AI application to capabilities
Model Context Protocol standardises how an AI host connects to external context and capabilities. An MCP server can expose:
- Resources for application-controlled context.
- Prompts for reusable templates and workflows.
- Tools for model-controlled actions such as querying a database or calling an API.
MCP is a good fit when the model needs to use a capability. In the Starbucks ChatGPT app, the MCP server exposed product search, menu, store, cart and checkout tools to the ChatGPT application. The important boundary was clear: ChatGPT decided which tool to call, while the application owned validation, session state and the actual business operation.
MCP does not turn a tool into an autonomous agent. It gives an AI application a consistent way to discover and use tools and context. Authentication, consent, rate limits and authorisation still belong in the product around it.
A2A: connect one agent to another
Agent2Agent addresses a different boundary. It lets independent agents communicate, discover capabilities and collaborate without exposing their internal prompts, memory or implementation.
That matters when the other side is genuinely another agent rather than a function. A travel agent might delegate hotel research to a hotel agent. A purchasing agent might negotiate with a seller agent. The caller does not need to know how the remote agent reasons or which tools it uses internally.
A2A gives agents a shared interaction model for messages, tasks, artefacts, streaming and longer-running work. It is designed for HTTP-based communication between separately deployed systems.
The short version is:
| Boundary | Useful standard | What it connects |
|---|---|---|
| Model to function or data | Tool calling or MCP | An AI application to capabilities |
| Agent to agent | A2A | Independent agents and their tasks |
| Application to service | HTTP, REST, GraphQL or events | Conventional software components |
| Agent behaviour to workflow | Skills and prompts | Instructions, knowledge and repeatable work |
Where OpenAPI and webhooks fit
Not every AI integration needs an AI-specific protocol. If a service already has a good REST API, OpenAPI schema or webhook contract, use it. The model can call a carefully wrapped function, and the function can call the existing service.
Protocols are most useful when several products need the same boundary. MCP becomes valuable when many AI hosts should use the same tools. A2A becomes valuable when separately owned agents need to collaborate. A normal API is often the better choice for a deterministic service-to-service call.
How I choose
I start with the smallest boundary that solves the problem:
- Use a normal function when the capability is private to one application.
- Use MCP when an AI host needs portable access to tools, resources or prompts.
- Use A2A when another autonomous system needs to collaborate as an agent.
- Keep the underlying APIs boring, observable and independently secure.
The protocol is not the product. It is the contract at the edge of the product. The design work is deciding what crosses that edge, who is allowed to trigger it, and how the system behaves when the other side is slow, wrong or unavailable.