The Short Version: Two Protocols, Two Different Jobs
If you have read anything about building AI agents in the last year, you have run into an alphabet soup: MCP, A2A, ACP, and a handful of smaller names. Most of the confusion clears up once you see that the two that matter solve different problems. MCP connects one agent to the tools and data it needs. A2A connects agents to each other. Everything else is either a layer on top of those two or has already folded into them.
That distinction is the whole decision. If you are building one assistant that needs to read your CRM, query a database, and call an internal API, you are in MCP territory. If you are building several specialised agents that need to hand work to one another, possibly across teams or even across companies, A2A is the layer that lets them do it without each pair being custom-wired. Most businesses start with the first and only reach the second once the first is working.
This article explains what each protocol actually does, which one your project needs right now (often neither, yet), what they change about security, and what adopting them costs in practice. It assumes you already know what an agent is; if not, our explainer on AI agents versus agentic AI covers that ground first.
What MCP Actually Does (Agent to Tools)
The Model Context Protocol is an open standard for connecting an AI application to external systems. The official MCP documentation describes it as a USB-C port for AI: one standard connector instead of a bespoke integration for every tool. It started inside Anthropic and is now an open project with support across Claude, ChatGPT, VS Code, Cursor and a long list of other clients, so a server you build once can be used by more than one AI product.
The moving parts are simple. An MCP host is the AI application (a chat product, an IDE, your own agent). The host opens an MCP client connection to each MCP server it wants to use. A server is any program that exposes three kinds of things, as defined in the MCP architecture overview:
- Tools: functions the model can call to do something, such as run a query, create a ticket, or send a message.
- Resources: data the model can read for context, such as a file, a database schema, or an API response.
- Prompts: reusable templates that shape how the model approaches a task.
Under the hood it is JSON-RPC 2.0 over one of two transports: stdio for a server on the same machine, or Streamable HTTP for a remote one, with OAuth recommended for authentication. The current spec revision (2026-07-28) made the protocol stateless. You do not need any of that to decide whether to use it, but it is why an MCP server is, in practice, just another well-described API that sits behind the same API layer you already run.
What MCP does for a business is turn integration from a per-agent cost into a per-system cost. Build one MCP server in front of your order database and every agent you ship afterwards gets access through the same door, with the same permissions. That is a very different economics from writing custom glue code inside each agent, and it is the main reason AI integration services engagements increasingly start with an inventory of which systems deserve an MCP server rather than a list of features.
What A2A Actually Does (Agent to Agent)
The Agent2Agent protocol handles the other direction. Where MCP gives a single agent access to tools, A2A lets independent agents discover each other, hand off tasks, and exchange results without sharing their internal logic. The A2A project site puts it plainly: MCP is for agent-to-tool communication, A2A is for agent-to-agent communication, and the two are meant to be used together.
A2A was originally developed by Google and has since been donated to the Linux Foundation, where it is governed by a technical steering committee that includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow. That governance detail matters more than it sounds. It is the signal that A2A is not one vendor's lock-in play, and it is why it is a safer bet for anything you expect to run for years.
The core idea is an Agent Card: a published description of what an agent can do and how to reach it. Another agent reads the card, sends a task, and gets back messages and artifacts as the work progresses. The protocol documentation describes the split as MCP being vertical and A2A being horizontal: MCP deepens what one agent can do, A2A widens how far a system of agents can reach. Tools have fixed, structured inputs and outputs and are usually stateless. Agents reason, plan, use several tools, and keep state over a longer interaction. That difference is exactly why they get different protocols.
What Happened to ACP and the Other Protocols
You will still see ACP, the Agent Communication Protocol, mentioned in older articles as a third contender. It is no longer a separate choice. The ACP project site now states that ACP is part of A2A under the Linux Foundation and points to a migration guide. If a vendor pitches you an ACP-based architecture today, ask which A2A version it maps to.
Beyond those, most names you encounter are frameworks, not protocols: orchestration libraries that help you build an agent and increasingly speak MCP and A2A underneath. A framework is a build-time choice; a protocol is an interoperability choice that outlives it. Treat any framework that cannot speak the open protocols as a future migration cost.
Do You Need These Yet? A Decision Table
The honest answer for a lot of projects is not yet, and that is fine. Protocols pay off at the second integration and the second agent, not the first. Use the table to place your project.
Guidance, not a rule. The dividing line is whether you have more than one agent that needs to coordinate, not how big the project is.
| Your situation | MCP | A2A | What to do instead |
|---|---|---|---|
| One assistant, one or two tools, internal use only | Optional | No | Direct function calling is fine; keep the tool definitions clean so they can become an MCP server later |
| One assistant, several business systems (CRM, ERP, database, ticketing) | Yes | No | Build one MCP server per system; the agent and any future agent share them |
| Several specialised agents inside one team or product | Yes | Probably | Start with MCP for tools; add A2A once agents need to delegate to each other rather than just share tools |
| Agents that must work with another department's or partner's agents | Yes | Yes | A2A is the only sane way to do this without pairwise custom integrations |
| Buying an off-the-shelf AI product and wiring it to your data | Yes | No | Ask the vendor whether it is an MCP client; if it is, you build servers, not plugins |
Two practical notes. First, even when you skip MCP for a first build, write the tool definitions as if they were an MCP server: clear names, typed inputs, descriptions a model can read. That makes the later upgrade a packaging exercise rather than a rewrite. Second, model choice is independent of all this. The protocols are model-agnostic by design, so you can follow our guide to choosing an AI model for production without it changing anything here.
A Worked Example: One Agent Becoming Three
This is a hypothetical to make the layers concrete, not a client engagement. Picture a mid-sized logistics company that starts with a single support agent. Customers ask where their shipment is, the agent needs to read the tracking database and the carrier's API, and occasionally it needs to open a ticket. Three systems, one agent. The right move is three MCP servers, one per system, with the agent as the MCP host. No A2A anywhere.
Six months later the same company wants a claims agent that handles damaged deliveries and a dispatch agent that re-routes trucks. All three need the tracking data, so the existing MCP server is reused unchanged. But now the support agent sometimes needs to hand a conversation to the claims agent, and the claims agent sometimes needs dispatch to confirm a pickup. That handoff is the A2A layer: each agent publishes an Agent Card, and the support agent delegates a task to the claims agent the same way it would to a colleague, without knowing how the claims agent is built or which model it uses.
Notice what did not change: the MCP servers. That is the economic argument in one sentence. Tool integrations built on MCP survive the move from one agent to many, which is where most of the budget would otherwise go. It is the same reason a properly designed enterprise software platform outlives the features built on top of it, and it is what makes multi-agent work a tractable scope for AI agent development rather than an open-ended one.
The Security Questions Nobody Asks Until Launch
A protocol that makes it easy for an agent to reach your systems also makes it easy for an attacker who controls the agent, or a tool the agent trusts, to reach them. The MCP project publishes a security best practices page that is worth reading before your first server goes live. The issues it names are not exotic; they are the ordinary mistakes of any integration layer, with higher stakes because a model is making the calls.
- Confused deputy: an MCP server that proxies to a third-party API with one shared credential can be tricked into acting for the wrong user. The fix is per-client consent before the server forwards anything.
- Token passthrough: a server that accepts a token issued for some other service and forwards it downstream. The spec forbids this outright; servers must only accept tokens issued to them.
- Over-broad scopes: granting an agent every permission up front so the demo works. Start with the minimum and step up only when a specific operation needs it.
- Local server compromise: an MCP server that runs on a laptop runs with that user's privileges. Any one-click install flow must show the exact command and get explicit approval.
- Server-side request forgery: a malicious server can hand your client a URL that points at an internal address or a cloud metadata endpoint. Clients that run on your infrastructure need to block private ranges.
None of these are reasons to avoid the protocols. They are reasons to treat an MCP server as a production API with an identity, an audit trail and a scope model, not as a demo script. That is the same bar we apply in our security practices for any integration, and it is why an agent project that touches customer data should include a cloud security review of the server layer before launch rather than after an incident.
A2A adds one more dimension: trust between agents. An Agent Card is a claim about capability, and your agent will act on it. For agents inside your own organisation that is manageable. For agents belonging to partners, you need the same discipline you would apply to any third-party software integration: authenticate the counterpart, limit what it can ask for, and log every task that crosses the boundary.
What Adopting These Protocols Costs in Practice
The protocols are free and open. The cost is engineering time, and most of it has nothing to do with the protocol. An MCP server for a well-documented internal API is days of work for a read-only server. One for a legacy system with no clean API, unclear permissions and three teams who each own part of the data is a different project, and that is the kind of scoping an AI development partner should do before quoting, not after.
Three rules of thumb, as editorial judgement rather than a quote. The first MCP server takes longest, because that is where authentication, scope design and hosting get settled. The security review is a real line item for anything touching customer or financial data. And A2A adds a design phase before any code: deciding which agent owns which decision is the hard part.
For budgeting the surrounding work, the drivers are the same ones in our AI development cost breakdown: integrations, data readiness, evaluation, and the team you put on it. If you are weighing in-house versus outside help, the figures in our piece on the cost to hire AI developers are a useful baseline, and for larger programmes the planning sections of our enterprise LLM development guide cover how to phase it. If the open question is simply whether your current systems are ready to sit behind an MCP server at all, a short AI consulting engagement scoped to that inventory will answer it faster than a proposal will.
One last thing worth saying plainly: the protocols do not make a bad agent good. A retrieval pipeline that returns the wrong documents returns them just as confidently over MCP. If your agent's problem is answer quality rather than connectivity, look at the RAG and retrieval layer first; if it is conversational design, look at how the chatbot or assistant itself is built. Reach for MCP and A2A when the problem is that your agent cannot get to what it needs, or your agents cannot get to each other.
Deciding Whether Your Agent Project Needs MCP or A2A?
Tell us what systems the agent has to reach and whether more than one agent is in the plan. We will tell you which protocol layer you actually need, which you can skip for now, and what the server layer should look like before it touches real data.
