Which Agent Protocol Do You Need?

Pick the right agent protocol: MCP, A2A, ACP, or plain function calling

There are now several standards competing for the same mental slot, and the names do not help. MCP, A2A, ACP and native function calling all involve an AI model calling something that is not itself. They are not alternatives to each other. Each one standardises a different edge of an agent system, and the reason teams pick wrong is that they start from "which protocol is winning" instead of "which two things am I connecting".

This selector asks that question first. It is a small deterministic decision tree — no scoring, no model, no network call. You choose what you are connecting, answer at most one follow-up, and get a named recommendation with the reasoning, who maintains it, and a link to the primary documentation. Everything runs in your browser; nothing you click is transmitted anywhere.

How the decision is actually made

Question one does the real work. Its four answers map one-to-one onto the four recommendations:

The two follow-up questions are conditional and refining, not deciding. "Local or remote?" appears only on the agent-to-tools path, and it changes the wording of the MCP advice rather than the protocol. "Cross-vendor interop needed?" appears only on the agent-to-agent path and does the same for A2A. Whichever way you answer those, the recommendation itself is fixed by question one. That is worth knowing before you agonise over them.

The four answers, in detail

Agent to tools and data → MCP

You have an agent and you want it to read files, query a database, hit an internal API, or use something a colleague wrote. MCP is exactly this surface. An MCP server exposes tools, resources and prompts; any MCP-capable client — Claude, Cursor, VS Code, Codex CLI and a growing list of others — can consume it with no bespoke glue. Write the server once, use it from every client you own.

The local-or-remote follow-up decides how you wire it up rather than whether to use it:

• Local process — a stdio server. Your client config carries a command and an args array, and the client spawns the process and talks over standard input and output. Best when the tool needs your filesystem, your credentials, or your machine.
• Remote service — an MCP server over Streamable HTTP, configured with a url entry. Best when the tool is a shared service, when it must be centrally updated, or when the data lives somewhere your laptop should not hold.

Agent to other agents → A2A

You have more than one agent, they run independently, and one needs to hand work to another. A2A gives each agent a published Agent Card at /.well-known/agent-card.json describing its skills and capabilities, so peers can discover it and invoke it over a standard transport without a hard-coded integration.

The interop follow-up is a candour check. If the agents come from different vendors, cross-vendor discovery is the whole reason A2A exists and the answer is clear. If everything is yours and in one process, the tool tells you so: A2A still keeps the agents loosely coupled, but you could equally just call them as functions and skip the protocol. That is a genuinely useful thing for a selector to admit.

One model, tools you own → native function calling

One model, one codebase, one vendor, tools you wrote and execute yourself. A wire protocol buys you nothing here. Declare the tools in the provider's own schema — OpenAI function objects, Anthropic tools with an input_schema — and run them in your app. The upgrade path is clean: when you later want the same tools available to other clients or processes, wrap them in an MCP server and the reuse is free. Starting with MCP for a single-app integration is a common way to add a process boundary you did not need.

Editor or CLI to a coding agent → ACP

This is the case people most often miss, because it looks like the others. You are building a front end — an editor, an IDE plugin, a terminal UI — and the agent on the other side owns its own runtime, its own model and its own tools. You are not giving it tools; you are driving it. ACP standardises that editor-to-agent channel over JSON-RPC, with stdio for local agents, so any ACP editor can drive any ACP agent. Zed, JetBrains and Google's Gemini CLI already speak it. The tool describes it as "the LSP for AI agents", which is the right analogy: it standardises the client side of a relationship, not the capability side.

ACP and MCP stack rather than compete. ACP handles the editor-to-agent surface; the agent underneath still typically uses MCP to reach its own tools and data.

The mistake this tool exists to prevent

The single most common error is treating MCP and A2A as a choice. They are complementary. A realistic agent uses MCP downward to reach its tools and A2A outward to delegate to peers, and the tool repeats this in both directions so you cannot miss it. If your architecture has both an agent-tool boundary and an agent-agent boundary, you do not pick — you implement both, and each one is simpler than the fused thing you would otherwise invent.

The second most common error runs the other way: reaching for a protocol when a function call would do. Every protocol adds a process boundary, a serialisation format, a configuration file, a failure mode where the transport is fine but the handshake is not, and a version to keep in step. That cost is worth paying for reuse and interop. It is not worth paying inside one application that talks to one model.

Quick comparison

Working through a real architecture

Say you are building an internal research assistant. It needs to search your document store, it needs to hand financial questions to a separate finance agent another team maintains, and your developers want to drive it from their editor. Run the selector three times and you get three answers, all correct:

• Document store → agent-to-tools, remote → MCP over Streamable HTTP, a url entry pointing at a shared server.
• Finance agent → agent-to-agent, cross-vendor → A2A, with each side publishing an Agent Card.
• Editor front end → editor-to-agent → ACP, wrapping the assistant so any ACP-capable editor can drive it.

Three boundaries, three protocols, no conflict. If instead you had asked "should we standardise on MCP or A2A", you would have spent a week on a question with no answer.

Using the output

Each recommendation panel gives you the protocol name, who maintains it, a one-line statement of what it is for, the reasoning specific to your answers, a note on what it composes with, and a link to the primary documentation site. The Copy recommendation button puts all of that on your clipboard as plain text — the format is designed to be pasted into a design doc or an architecture ticket, which is usually where this decision needs to be written down and defended. Start over resets every answer, and changing question one clears the follow-ups so a stale answer cannot leak into a new path.

Once you have your answer, the next step differs by path. For MCP you need a client configuration file, and the shape differs by client. For A2A you need a published Agent Card. For function calling you need a tool schema in your provider's format. Each of those has its own generator on this site.

Honest limits

• It recommends exactly four things. Protocols outside that set are not considered.
• It is a decision tree, not an evaluation. It does not weigh maturity, ecosystem size or operational cost against each other.
• It says nothing about authentication, authorisation or transport security. Those are real work on every path and are not part of the recommendation.
• The follow-up questions refine the explanation only. The protocol is determined by your first answer.
• This is a fast-moving area. The recommendations reflect what each protocol is designed for, and that is stable; the specific version and feature details on each protocol's own site are not, so follow the links before you commit to an implementation.

What each answer asks of your infrastructure

The recommendation tells you which protocol fits. It does not tell you what adopting it costs, and the costs differ enough to be worth budgeting for before you commit.

MCP costs you a configuration file per client, multiplied by every developer who needs the server. Local stdio servers additionally inherit whatever environment the client spawns them in, which is rarely your interactive shell — PATH problems are the characteristic MCP failure. Remote servers move that cost to hosting and authentication instead. The upside is real reuse: one server, every client.

A2A costs you a public, unauthenticated, permanently reachable document, plus the discipline to keep it accurate as the agent changes. Discovery happens before any handshake, so the card must be fetchable by parties you have not met. That is a deployment and a governance question as much as an engineering one.

ACP costs you the launch and handshake wiring between a front end and an agent process, and it only pays off if either side is genuinely swappable. Building both halves yourself and never intending to interoperate is the case where the standard earns least.

Function calling costs almost nothing up front and charges you later, in lock-in: the schema is provider-specific, and moving to another vendor means rewriting every tool definition. That is a reasonable trade for a single-vendor application and a bad one for a platform.

None of the four gives you authentication, authorisation or auditing for free. Whichever way the selector points, deciding who may invoke what remains your work.