By the Notion Tech team · Published 15 November 2026 · Protocol details checked against the official MCP and A2A specifications on 15 November 2026
Most businesses we talk to are still working out what one AI agent should do. Then a vendor demo shows three agents chatting to each other, someone mentions “A2A”, and the question in the room changes to: do we need that too?
Probably not yet. But it’s worth understanding why, because the two protocols behind most agent talk, MCP and A2A, solve different problems. Mix them up and you either overbuild a simple assistant or try to stretch a tool connection into something it was never designed to carry.
The short answer: MCP (Model Context Protocol) is how one agent plugs into tools and data, like your CRM, your inbox or an accounting system. A2A (Agent2Agent) is how one agent hands work to a different agent, often one owned by another team or another company, and tracks that work until it’s done. Most businesses need MCP first. A2A starts to matter when the other side of the conversation is an agent you don’t control.
This piece explains what each protocol actually does, where they overlap, what the security trade-offs look like, and a simple test for deciding which one a project needs. There’s one short code example, because seeing an Agent Card makes the idea click faster than describing it.
Two protocols, two directions
The cleanest description we’ve found comes from the A2A project itself. Its comparison page calls MCP “vertical” and A2A “horizontal”.
Vertical means depth. Every MCP connection you add gives a single agent another tool or data source, so that agent can do more on its own. Horizontal means reach. A2A connects your agent to other agents across a boundary: another department, a partner, a supplier. The page sums it up in one line: “MCP gives each agent depth, and A2A gives your system reach.”
A practical way to hold the difference in your head: a tool does what it’s told and returns a result. An agent can push back. It might ask a follow-up question, take three days to finish, refuse the job, or come back with a draft that needs approval. MCP is shaped around the first kind of thing. A2A is shaped around the second.
What MCP is for
Anthropic open-sourced MCP in November 2024 as a standard way to connect AI assistants to “the systems where data lives”. Instead of building a custom connector for every pairing of AI app and business system, you build one MCP server for a system, and any MCP-capable app can use it.
The current MCP specification (version 2026-07-28) describes three roles. The host is the AI application your staff use. The client is the connector inside it. The server is the thing that offers capabilities. Servers offer three kinds of feature: tools the model can run, resources (data and context) and prompts (templated workflows).
In business terms, MCP is how you let an assistant look up a customer in your CRM, read a job sheet, check stock or draft an invoice in your accounting system. The agent stays in charge. The MCP server just does the specific thing it’s asked.
What A2A is for
Google announced A2A in April 2025 with more than 50 technology partners, and described it from day one as complementing MCP rather than replacing it. The idea is that a “client” agent formulates a task and a “remote” agent works on it, even if the two were built by different vendors on different frameworks.
The A2A specification is built on a few concepts worth knowing by name:
- Agent Card: a JSON document an agent publishes to describe who it is, what skills it offers, where to reach it and how to authenticate. The spec’s standard location is
/.well-known/agent-card.jsonon the agent’s domain, though cards can also come from registries or direct configuration. - Task: the unit of work. Tasks have an ID and move through a lifecycle, including states for completed, failed, cancelled and rejected, plus two “interrupted” states where the remote agent needs more input or needs authorisation.
- Message and Parts: the back-and-forth between agents. Parts can be text, files or structured data.
- Artifact: the output, such as a document, an image or a set of figures.
One design choice matters a lot for business use. The spec calls it “opaque execution”: agents collaborate based on what they declare and exchange, “without needing to share their internal thoughts, plans, or tool implementations”. Your supplier’s agent doesn’t have to show you its database or its prompts. It just has to accept the task and return a result.
MCP and A2A side by side
Here’s the comparison in one place, using only what the two specifications and their official pages say.
| Aspect | MCP (Model Context Protocol) | A2A (Agent2Agent Protocol) |
|---|---|---|
| Connects | One AI application to tools, data and prompts | One agent to another agent |
| Direction | Vertical: gives a single agent more capabilities | Horizontal: lets agents work across teams and organisations |
| Typical other side | A system you own or license: CRM, inbox, database, accounting software | An agent that may belong to another team, partner or vendor |
| Unit of work | A tool call or resource read | A task with a lifecycle (working, needs input, completed, failed and so on) |
| How the other side is described | Tool names and input schemas listed by the server | An Agent Card listing skills, endpoints and security requirements |
| Long-running work | Optional Tasks extension in the 2026-07-28 spec | Core design goal, with streaming and push notifications |
| Created by | Anthropic, November 2024 | Google, April 2025 |
| Current version | Spec revision 2026-07-28 | v1.0 stable spec (v1.0.1 patch release, May 2026) |
| Governance | Linux Foundation’s Agentic AI Foundation (since December 2025) | Linux Foundation’s Agentic AI Foundation (since August 2026) |
The last row is the one people often miss. Both protocols now sit under the same neutral body, so the “Anthropic standard versus Google standard” framing that floated around in 2025 doesn’t hold up any more.
Same family now: what changed in 2026
A year ago it was reasonable to worry that these were rival bets. The past 12 months have mostly settled that.
In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP joined Block’s goose and OpenAI’s AGENTS.md as founding projects.
In March 2026, A2A shipped its first stable specification. According to the AAIF’s announcement, version 1.0 added multiple protocol bindings with version negotiation, multi-tenancy and signed Agent Cards. The project’s release notes also show it dropped older OAuth flows in favour of PKCE and device code flows, and a 1.0.1 patch followed in May. A 1.1 release candidate is tagged on GitHub, but it isn’t a stable release yet, so we wouldn’t build against it.
In July 2026, MCP made its biggest change so far. The 2026-07-28 revision removed protocol-level sessions and the start-up handshake, so every request carries what the server needs to answer it. It also moved long-running tasks into an official extension and introduced a pattern where a server can pause and ask for more input, such as a person’s approval, before finishing a request. We covered the technical side of that in our guide to building a stateless MCP server.
In August 2026, A2A joined the AAIF too. The A2A project’s own post describes MCP as “the vertical integration layer connecting agents to internal tools and databases” and A2A as “the horizontal protocol enabling peer-to-peer collaboration”.
And on 11 November, Google’s open source team published an interview noting that the Agent Skills format has also joined the AAIF alongside MCP, as a way to load procedural instructions only when an agent needs them. That’s a third layer again, and a reminder that “which protocol?” usually has more than one answer.
| Date | What happened | Source |
|---|---|---|
| 25 Nov 2024 | Anthropic open-sources MCP | Anthropic |
| 9 Apr 2025 | Google announces A2A with 50+ partners | Google Developers Blog |
| 9 Dec 2025 | Agentic AI Foundation formed; MCP donated | Anthropic, Linux Foundation |
| 12 Mar 2026 | A2A v1.0, first stable spec | A2A GitHub releases |
| 28 Jul 2026 | MCP spec goes stateless (2026-07-28) | MCP changelog |
| Aug 2026 | A2A joins the Agentic AI Foundation | AAIF, A2A blog |
What an Agent Card looks like
This is the one bit of code in the article, and it’s here because it explains A2A better than a paragraph would. Below is a cut-down, made-up Agent Card for a supplier’s quoting agent. The field names follow the structure of the sample card in the A2A v1.0 specification. The company, URLs and skill are invented for illustration.
{
"name": "Example Supplies Quote Agent",
"description": "Checks stock and prepares trade quotes for plumbing parts.",
"version": "1.0.0",
"supportedInterfaces": [
{
"url": "https://agents.example-supplies.com.au/a2a/v1",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"capabilities": { "streaming": true, "pushNotifications": false },
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["application/json"],
"skills": [
{
"id": "trade-quote",
"name": "Trade quote",
"description": "Prices a parts list for an approved trade account.",
"tags": ["quotes", "stock", "plumbing"]
}
]
}Read it like a business card for software. It says what the agent is called, what it can do, where to send work and what formats it accepts. A real card would also declare security schemes, for example OAuth or OpenID Connect, so your agent knows how to prove who it is before sending anything. The spec also lets providers sign their cards so a client can check a card hasn’t been tampered with.
Notice what’s missing: nothing about the supplier’s pricing rules, stock database or which AI model they use. That’s the opaque execution idea in practice.
A worked example: one quote, both protocols
Abstract comparisons only go so far, so here’s a hypothetical. Picture a mid-sized plumbing business that wants an assistant to turn customer enquiries into draft quotes.
The office assistant is one agent. Through MCP, it connects to the business’s own systems: the shared inbox to read the enquiry, the job management software to check the customer’s history, and the price book. Those are tools. They do exactly what they’re asked and return a result in a second or two.
Now the job needs a part the business doesn’t stock. Its main supplier has launched its own quoting agent, built on a different platform. This is where A2A earns its place. The plumber’s assistant finds the supplier’s Agent Card, sends a task (“price these six parts for delivery to Parramatta on Thursday”) and gets back a task ID. The supplier’s agent might reply that one part is back-ordered and ask whether a substitute is acceptable. That’s the “input required” state in the A2A task lifecycle. A person in the plumber’s office says yes, the task continues, and a priced parts list comes back as an artifact.
Inside the supplier’s business, their agent is almost certainly using its own MCP connections to check stock and pricing. The A2A specification describes exactly this pattern in its appendix: an A2A server agent “might use MCP to interact with several underlying tools, APIs, or data sources” to complete a task.
Could you do the same thing with MCP alone? Partly. The supplier could publish an MCP server with a get_quote tool, and for a simple, instant lookup that would be fine, and simpler. The A2A project itself says an agent can expose well-defined, stateless skills as MCP-style tools. The case for A2A gets stronger when the work takes time, needs back-and-forth, or when the supplier wants its agent to make judgement calls it doesn’t want to expose as a list of raw tools.
A quick test: which one does your project need?
We use five questions when scoping agent work. They aren’t from either spec. They’re our rule of thumb, so treat them as a starting point.
- Who owns the other side? If it’s your own system or a SaaS product you license, start with MCP. If it’s another organisation’s agent, look at A2A.
- Is it a lookup or a job? “What’s this customer’s balance?” is a tool call. “Prepare a compliance pack for this site and tell me what’s missing” is a task.
- How long does it take? Seconds suits a tool. Hours or days, with progress updates along the way, suits A2A’s task model.
- Will the other side need to ask questions? If the answer depends on clarification or a person’s approval mid-way, A2A was designed for that. MCP’s 2026-07-28 revision has also added ways for a server to request input, so this gap is smaller than it was.
- Do you want to see inside? If you need full control of every step, keep it as tools under your own agent. If you’re happy to trust a partner’s agent with the how and judge it on the result, A2A fits.
| Scenario | Start with | Why |
|---|---|---|
| Assistant reads your inbox and updates your CRM | MCP | Both systems are yours; these are discrete tool calls |
| Staff assistant answers questions from your policies and job history | MCP | Retrieval from your own data sources |
| Your booking agent asks a partner clinic’s agent for an available appointment | A2A | Another organisation’s agent, with back-and-forth |
| Several of your own specialist agents inside one platform | Usually neither at first | Most agent frameworks handle hand-offs internally; add A2A if they need to cross platforms |
| A customer’s AI assistant wants to place an order with your business | A2A (plus MCP behind it) | You expose an agent to the outside; it uses your tools internally |
| Instant price lookup from a supplier’s system | MCP or a plain API | Short, stateless, well defined: no need for a task lifecycle |
The fourth row is worth a pause. If all your agents live in one framework, built by one team, that framework’s own hand-off features are often enough. A2A pays off at boundaries: between frameworks, between clouds, between companies.
Where A2A is already showing up
We want to be careful here, because adoption claims are easy to inflate. These are the claims made by the projects themselves, not our own testing.
The AAIF says A2A is backed by more than 150 organisations and lists production use across mobile platforms, cloud AI infrastructure, financial services and supply chain. It names specific examples: Huawei using A2A between its Celia assistant and in-app agents on HarmonyOS, Tencent’s WeChat integrating with Android phone-maker assistants, and A2A support in Google Cloud’s agent tools, Microsoft Azure AI Foundry and AWS Bedrock AgentCore. The A2A project’s post adds that frameworks including LangGraph, CrewAI, Pydantic AI, AG2 and IBM BeeAI support it.
MCP’s adoption is broader. When Anthropic donated it in December 2025, it said there were more than 10,000 active public MCP servers and that MCP had been adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, among others.
For an Australian small or mid-sized business, the honest reading is this: you’ll meet MCP almost immediately, because the AI tools your staff already use support it. You’ll meet A2A when a large partner, supplier or platform starts offering an agent you’re expected to work with. That’s happening at enterprise scale now. For most smaller firms it’s more likely to arrive through a platform you already use than through a project you start.
Security and governance: the questions to ask
Both protocols move real data and can trigger real actions, so the risks deserve plain language.
MCP risks
The MCP specification is blunt that tools “represent arbitrary code execution and must be treated with appropriate caution”, and that hosts must get explicit user consent before invoking any tool. Its security best practices page lists specific attacks, including servers that pass a user’s token straight through to another system, local servers that run malicious commands, and access tokens with far broader permissions than the job needs. The page recommends starting with a minimal set of scopes and asking for more only when a sensitive action is first attempted.
The bigger everyday risk is prompt injection. If an MCP-connected agent reads emails or web pages, someone can hide instructions in that content. We wrote about this in our piece on what AI agents do well for small businesses: anything that moves money, deletes records or contacts customers should need a person’s approval.
A2A risks
A2A widens the circle of trust. You’re now accepting work from, or handing work to, software another organisation runs. The A2A spec requires servers to check authorisation on every request and to scope results to what the caller is allowed to see. It supports standard schemes such as OAuth 2.0, OpenID Connect and mutual TLS, and signed Agent Cards help confirm a card really came from the claimed provider.
What the protocol can’t do is decide whether you should trust the other party. A signed card proves who published it, not whether their agent is any good or handles your data properly. That’s a commercial question, and it belongs in a contract.
Questions we’d ask before connecting to any outside agent:
- What data will our agent send, and does it include personal information?
- Where is the other agent hosted, and where will our data be processed and stored?
- What can the other agent do in our name, and can we cap it, for example by order value?
- How do we see what happened if something goes wrong? Are task histories and logs kept, and for how long?
- What happens when their agent is down or changes its skills without notice?
The Australian angle
Sending a task to another organisation’s agent can be a disclosure of personal information. If that agent is hosted overseas, Australian Privacy Principle 8 on cross-border disclosure is relevant. It sets out the steps an organisation covered by the Privacy Act must take before personal information goes offshore. Opaque execution cuts both ways here: the same design that protects the partner’s internals also means you can’t see how they handle your customer’s data unless you ask.
And if a chain of agents ends up making or substantially shaping a decision about a person, such as approving a refund or allocating a service, the Privacy Act changes that start on 10 December 2026 apply. Our explainer on the automated-decision rules covers what that means for your privacy policy. We’re not lawyers, so get proper advice for your situation. Our summary of Australia’s AI safety rules gives the broader context.
The honest trade-offs
Neither protocol is free to adopt, and some of the excitement around multi-agent systems runs ahead of what most businesses need.
A2A adds moving parts. Every agent-to-agent hop is another place for a task to stall, a message to be misread or a cost to pile up. If one well-connected agent with good MCP tools can do the job, that’s usually cheaper to build, easier to test and simpler to explain to staff.
Opaque agents are harder to debug. When a partner’s agent returns a wrong answer, you can see the task and the artifact, but not the reasoning. You’re relying on their logs and their goodwill to work out what happened.
Standards are still moving. MCP’s 2026-07-28 revision was a breaking change for anyone who built on sessions. A2A 1.0 made breaking changes from version 0.3, which the spec lists in a migration appendix, though an agent can offer interfaces for more than one version while clients catch up. Expect more change, and keep your business logic in your own systems so a protocol upgrade doesn’t mean a rebuild. Our guide to custom versus off-the-shelf software covers that kind of lock-in thinking in more detail.
MCP has its own sprawl problem. Google’s interview with MCP and Agent Skills maintainer Kurtis Van Gent describes “tool and context bloat” as agents connect to dozens of MCP servers. More connections don’t automatically make a better agent. A short list of well-described tools usually beats a long one.
Not everything needs a protocol. A fixed, well-understood integration between two systems is often best built as a plain API integration with no AI in the middle. Protocols help when an AI model needs to choose what to call. If nothing needs choosing, skip it.
What we’d do this quarter
If you’re planning agent work in the next few months, here’s a short, practical sequence.
- Start with one agent and MCP. Pick a frequent, well-documented job, connect only the systems it needs, and give it the narrowest permissions that work.
- Put approvals on anything with consequences. Payments, deletions, outbound messages and anything touching personal information should wait for a person.
- List your likely “other agents”. Which suppliers, platforms or partners are likely to offer an agent in the next year or two? That tells you whether A2A is a this-year question or a later one.
- Ask vendors straight questions. Does their product support MCP, A2A or both? Which versions? Can you see task logs? Where is data processed?
- Keep the logic yours. Prompts, test cases and business rules should live in your systems, so you can switch models, vendors or protocols without starting again.
If you’d like help working out where agents fit in your business, or want an MCP connection or A2A endpoint built with proper permissions and approvals, have a look at our AI agents and automation service. For connecting AI tools to the systems you already run, see our integrations and API development work.
