MCP and A2A: what open agent protocols buy you

The short answer: the Model Context Protocol (MCP) standardises the connection between an agent and the tools, data and services it uses. The Agent-to-Agent protocol (A2A) standardises how independent agents discover each other, exchange tasks and return results across organisational and vendor boundaries. Both are Linux Foundation projects. A platform that speaks them means your connectors and your agent-to-agent links are not proprietary wiring you would have to rebuild elsewhere.

Third-party figures on this page were checked on 26 September 2026 against the publishing organisation's own release or report. Research in this field ages quickly and definitions vary between surveys — treat any undated statistic with suspicion, including on our own pages.

Where each one sits

Scroll the table sideways to see every column.

The clean way to hold it: MCP is about capability — what an agent can do. A2A is about collaboration — who an agent can ask. A team of agents inside one deployment does not need A2A to talk to each other; A2A earns its place the moment one of the parties is outside your boundary.

What A2A reaching v1.0 actually changed

Two things, both commercial rather than technical. Landing in AWS, Microsoft and Google platforms means a large customer can now require A2A support in a procurement document and expect it to be met. And 150-plus supporting organisations with production deployments across supply chain, financial services, insurance and IT operations means it stopped being a demo protocol.

The near-term consequence for a smaller business is modest but real: the agent you build this year has a defined way to be called by a partner's system next year, without a bespoke integration project on both sides.

The four directions, and which ones you will actually use

Each protocol runs both ways, which produces four capabilities that are easy to confuse:

1. Consuming MCP servers. Your agent uses someone's tool. This is the one everybody uses, and the one worth checking first: how many servers, how is auth handled, what happens when a token expires. That last question is more operationally important than the count — see why MCP connections keep breaking.
2. Exposing an agent as an MCP server. Your agent becomes a tool other systems can call. Useful when a colleague's IDE, a partner's platform or an internal system should be able to ask your agent something. Covered in exposing your agent as an MCP server.
3. Sending over A2A. Your agent delegates to a remote agent it has been told about. The control that matters is that the list of addressable agents is configuration, not a parameter the model can invent.
4. Publishing an A2A agent card. Others can discover and call your agent. This is the one to enable deliberately and never by default, because it is an inbound door.

The questions worth asking a platform

1. Which directions do you support? "We support MCP" usually means direction one only. That is fine — but know it.
2. How are credentials scoped? A per-agent scope beats an account-wide one, and a secret the model never sees beats one pasted into a prompt.
3. What happens to an inbound call's permissions? A request arriving over MCP or A2A is not your operator. It should not inherit an operator's approval rights — it should land on the approval boundary like any other untrusted origin.
4. Is the address list configuration? If an agent can be talked into calling an arbitrary URL, the protocol has become an exfiltration path. This is the same reasoning as prompt injection containment.
5. What is logged? Cross-boundary calls are exactly the ones you will be asked to account for later.

Does an open protocol actually prevent lock-in?

Partly, and it is worth being precise about which part. Protocols make the edges portable: your connectors and your inter-agent links are re-creatable elsewhere because they follow a published spec. They do nothing for the middle — an agent's accumulated memory, its skills, its configuration and its history are not covered by either standard, and that is usually where the real switching cost sits.

So the protocol question is necessary and not sufficient. Ask it alongside the export question: can I take the agent's memory and history out, in a form something else could read? Platform lock-in and what it costs works through the full list, and are agent skills portable covers the part people assume is standardised and mostly is not.

Olano's position

Olano speaks both protocols in both directions. Agents consume MCP servers and can be exposed as one; agents send to remote A2A agents and can publish an agent card for inbound calls. Inbound requests over either protocol run as an external, non-owner origin, so they meet the approval boundary rather than bypassing it, and the addressable remote agents are configuration rather than something a model can improvise. The reference pages are MCP and A2A in the glossary, and channels and connectors in the docs.