MCP vs function calling vs A2A: which protocol does your agent need?

What does each term actually mean?

Function calling, also called tool use, is a feature of model APIs. You describe tools with a name, a description and a JSON Schema for arguments; the model replies with a structured request to call one; your code runs it and returns the result.

The Model Context Protocol, introduced by Anthropic as an open standard, defines how a client application talks to external servers that expose tools, resources and prompts. It uses JSON-RPC over transports such as stdio for local servers and HTTP for remote ones.

Agent2Agent, or A2A, was introduced by Google and is now developed as an open project with industry partners. It defines how independent agents discover each other through agent cards, send tasks, exchange messages and stream progress, regardless of which framework built them.

The confusion comes from overlap in vocabulary. All three talk about tools, tasks and messages, but they sit at different levels of the stack and answer different questions: how does the model request an action, where do tools come from, and how do separate agents cooperate?

How do MCP, function calling and A2A compare?

How do the three layers fit together?

Picture a travel assistant. The model inside it uses function calling to request actions. Many of those actions come from MCP servers, such as a calendar server and a maps server, which the host application connected at startup and presented to the model as tools.

When the assistant needs a flight booked, it may hand that whole job to a separate airline agent over A2A. The airline agent has its own model, its own tools and perhaps its own MCP servers, and returns a finished result rather than raw tool outputs.

So function calling is the model’s verb, MCP is the plug standard for tools and context, and A2A is how opaque agents collaborate as peers.

Keeping the layers separate in your head also keeps your architecture flexible. You can change model providers without touching MCP servers, swap an MCP server without retraining anything, and replace a remote agent without changing your own tools.

When is plain function calling enough?

If your tools live inside one application and only your own agent uses them, plain function calling is simplest. You define a handful of functions next to your code, validate arguments and you are done.

Adding MCP there brings a process boundary and a protocol for little benefit. Start plain and extract an MCP server when a second client, such as a coding assistant or a desktop chat app, needs the same tools.

Function calling is also where most reliability work happens regardless of protocol. Clear tool names, tight argument schemas, helpful error messages and small result payloads improve agent accuracy whether tools come from your code, an MCP server or anywhere else.

Validate every argument on the server side. The model’s output is a suggestion, not a trusted input, and a tool that deletes, pays or emails should check permissions exactly as a normal API endpoint would.

When should you build an MCP server?

Build an MCP server when you want one integration to work across many AI clients. Claude Desktop, Claude Code, several IDE agents and many open-source agent frameworks speak MCP, so a single server for your database, API or internal docs reaches all of them.

It is also the natural shape for products that want to be used by agents. Shipping an official MCP server lets customers plug your service into their assistant without custom glue code.

MCP also covers more than tools. Resources let a server expose readable context such as files or records, and prompts let it publish reusable templates. Many clients focus on tools first, so check which features your target clients actually support.

Local servers over stdio are easy to distribute as a package developers run on their own machine. Remote servers over HTTP suit hosted products and need proper authentication, which the specification addresses with OAuth-based flows.

When does A2A make sense?

A2A makes sense when the thing on the other side is not a tool but an agent with its own reasoning, state and long-running tasks. Examples include a vendor’s procurement agent, a research agent owned by another team, or a specialist agent built on a different framework.

If you control every agent in the system and they run in one process, an orchestration framework’s internal messaging is usually simpler than a network protocol. A2A earns its keep across organizational or vendor boundaries.

The protocol’s agent cards describe what an agent can do and how to reach it, which enables discovery. Tasks can be long-running, with status updates and streamed results, which suits work that takes minutes or hours rather than one request.

Adoption of A2A is earlier than MCP, so check that the agents and frameworks you care about actually implement it before designing around it.

Which should you choose?

Standards reduce integration work only when both sides implement them. Before committing, list the clients or agents you need to talk to and confirm what each actually supports today.

• One app, a few private actions: function calling.
• An integration many AI clients should use, such as your SaaS, database or knowledge base: an MCP server.
• A coding agent that needs your internal tools: MCP.
• Handing whole tasks to agents owned by partners or other teams: A2A.
• A multi-agent system inside one codebase: your framework’s native orchestration, with MCP for shared tools.
• Unsure: start with function calling, and extract to MCP or A2A when a second consumer appears.

Common mistakes and where these protocols break

• Wrapping every internal function as an MCP server, adding latency and processes without a second client.
• Connecting third-party MCP servers without reviewing what tools and permissions they expose.
• Trusting tool descriptions and outputs blindly; they are an injection surface.
• Giving a remote A2A agent more data or authority than the task requires.
• Exposing so many tools that the model picks the wrong one; curate and name tools clearly.
• Ignoring authentication on remote MCP and A2A endpoints; both specifications describe auth, but you still have to implement it.

How to adopt them step by step

Start by defining your tools as plain functions with strong schemas and tests. When a second AI client needs them, wrap the same functions in an MCP server rather than rewriting them.

Only when you need to delegate whole tasks across a team or vendor boundary, expose an agent over A2A with a clear agent card, scoped permissions and logging of every task it accepts.

Frequently asked questions

Does MCP replace function calling?

No. MCP builds on it. The host application reads tools from MCP servers and presents them to the model, which still uses its API’s function calling to request a call. MCP standardizes where tools come from and how they are invoked, not how the model chooses them.

Is A2A a competitor to MCP?

They target different layers. MCP connects an AI application to tools and context, while A2A connects agents to other agents as peers. Google positioned A2A as complementary to MCP, and a single agent can expose itself over A2A while using MCP servers internally.

Which models support MCP?

MCP support lives in the client application rather than the model. Any model with function calling can use MCP tools if its host implements the protocol. Anthropic’s clients support it, and many other assistants, IDE agents and open-source frameworks have added MCP client support.

Is MCP secure?

The protocol can be used securely, but risk depends on which servers you connect. A malicious or compromised server can return misleading tool descriptions or outputs that manipulate the model. Review servers, limit permissions, require approval for sensitive actions and prefer well-maintained implementations.