MCP, A2A, and tool calling: agent protocols explained

The A2A protocol organizes exchanges between independent agents; MCP provides a common interface for connecting an AI application to tools and data. Tool calling lets a model request a structured operation that an application or service will execute. All of these mechanisms can contribute to the same task, each at a different point in the process.

Connections that serve different purposes

An agent cannot simply open your files or access your billing software on its own. Its application must make capabilities available, pass along requests, and retrieve results. When it calls on another agent, it must also manage a relationship with a system that has its own internal workings.

These terms can sound similar because they all involve exchanges. However, tool calling is a mechanism offered through model interfaces, with formats that vary by provider. MCP and A2A define standardized exchanges between software systems. The table below shows their responsibilities without treating them as competing solutions.

Reference point	Tool calling	MCP	A2A
Relationship managed	Model and execution environment	Client application and capability server	Client and remote agent
What is exchanged	Operation request and arguments	Tools, data, and instruction templates	Messages, tasks, and results
Discovery	Functions presented to the model	Capabilities exposed by the server	Capabilities described in an Agent Card
Main responsibility	Produce a usable call	Make an integration reusable	Organize collaboration between systems

The official documentation describes A2A and MCP as complementary. The distinction concerns the interface a service exposes: a complex service can be presented as a tool, and a remote agent can use tools internally.

For an introduction to the loop that selects and sequences these operations, AI agent or chatbot: what is the difference? explains the role of the application surrounding the model.

Tool calling: requesting a specific operation

Tool calling starts with a description: the function’s name, intended purpose, and accepted parameters. The model receives this description along with the user’s request. It can then produce a structured call instead of a response intended for someone to read.

In a hypothetical billing application, it might request an invoice search for a particular customer. The software checks the parameters, enforces permissions, queries the business system, and returns the result. The model can then explain that result or suggest another action.

This separation matters: producing a call does not mean executing it. Anthropic’s tool use documentation distinguishes tools executed by the application from those executed on the provider’s infrastructure. You therefore need to identify where each operation actually runs.

A parameter schema helps the model produce a usable request. It does not guarantee that it selected the right customer, that an amount is justified, or that the user requested the action. Those checks also depend on the software and its business rules.

For an application with a small set of internal functions, declaring those functions directly may be enough. Adding a connection protocol becomes useful when you need to share the same capabilities across applications, maintain capability discovery, or manage their execution separately from the assistant’s code.

MCP: a common interface for external capabilities

The Model Context Protocol separates the host application, the client that communicates with a server, and the server that exposes capabilities. That server can run on your machine or remotely. Here, “server” means a program; it does not require buying a dedicated computer.

According to the official MCP architecture, the host application coordinates its clients, each connected to a server. Local exchanges can use the process’s standard input and output streams; remote connections can use Streamable HTTP.

The intended benefit is a reusable interface. A service can expose capabilities through MCP instead of maintaining a separate integration for every application. This still requires configuration, and clients can differ in what they support.

The documentation distinguishes the capabilities offered by MCP servers:

• Tools, which perform an operation or retrieve information.
• Resources, which provide content to use as context.
• Prompts, which offer reusable instruction templates.

The application can present discovered tools to the model, receive its request through tool calling, and then pass the operation to the MCP server. The connection protocol and the mechanism used to request an action then work together.

An MCP server therefore does not necessarily choose an objective or carry out an entire assignment on its own. To explore available integrations, see the MCP server profiles. The Choosing an MCP server guide covers trust and permission criteria in more detail.

The A2A protocol: communicating with another agent

A2A, short for Agent2Agent, is intended for systems that need to communicate with an independent agent. The client sends a request without needing to know the agent’s model, memory, or internal tools. This separation allows the systems on either side to use different architectures.

The A2A key concepts distinguish the client that initiates the exchange from the remote agent that handles the request. The remote agent exposes an Agent Card describing its identity, skills, and interaction capabilities.

This card helps determine whether the service appears suited to an assignment. It is not a quality certification. A declared skill still needs to be evaluated using representative requests and explicit criteria for assessing the results.

A2A can be used to request an analysis from a specialized system, then continue the exchange if information is missing. The requester does not need to dictate every technical call. It does, however, need to specify the expected result and the constraints the agent must follow.

The term A2A protocol does not cover every conversation between agents. Subagents within the same application can communicate through internal mechanisms. A2A supplies an agreed framework for exchanges when an interaction crosses a boundary between systems.

Likewise, making an agent accessible through A2A does not prove that it can collaborate usefully. Its value depends on how work is divided: a clear responsibility and a verifiable deliverable are easier to work with than a vague delegation.

Tracking tasks and identifying deliverables

A request sent to a remote agent may require several exchanges. The A2A task lifecycle allows for an immediate message response or a task with a tracked status. That task can progress, request more information, fail, or finish.

The client application must interpret that status correctly. A task waiting for clarification should not appear as complete, and a failed task should not silently produce a substitute answer. The user interface is therefore part of the overall system’s reliability.

The A2A specification separates communication messages from artifacts, the deliverables associated with a task. It also provides different ways to receive updates, including polling, event streaming, and notifications, depending on the capabilities advertised.

For your application, this distinction makes it possible to separate a progress update from the final document you intend to use. You still need to define what makes that document acceptable: its expected format, the origin of its data, any missing information, and the checks it must pass.

A completed technical status means that the reported processing has finished. It does not guarantee that the resulting content is accurate. The guide to multi-agent systems helps assess the value of this delegation and the coordination work it adds.

Example: preparing invoice reminders

Consider a hypothetical scenario: you ask an application to prepare reminders for unpaid invoices, with approval required before sending. The main application needs to consult accounting data, handle exceptional cases, and present drafts for your review.

The mechanisms could work in the following sequence:

1. The application uses MCP to discover the invoice lookup tools it is authorized to use.
2. The model requests the lookup through tool calling; the application passes along the operation and retrieves the data.
3. If a specialized agent needs to review disputed accounts, the application delegates that analysis through A2A.
4. It tracks the remote task, retrieves its deliverable, and prepares the reminders for your approval.

This example illustrates a possible architecture, rather than a ready-to-use integration. Each connection requires actual support, appropriate permissions, and an agreement about the data being exchanged.

It also shows where controls belong. Reading an invoice, passing its contents to a remote service, and sending a message are separate actions. Permission to view information should not be interpreted as blanket permission to distribute it.

If the reminder rules are fixed, conventional automation may be sufficient. Choosing between platforms requires a separate assessment, covered in the n8n vs Make comparison. The protocol does not make that architectural decision for you.

Compatibility and security: check the entire process

An MCP-compatible or A2A-compatible label does not describe an entire integration. Check which capabilities are actually supported, how authentication works, how errors are handled, and how results are presented. A technically accepted exchange can still be unusable in your workflow.

The MCP security best practices address risks involving local servers, authorization intermediaries, and access token forwarding, among other issues. Connecting a local server means allowing a program to run, so its origin and permissions deserve scrutiny.

For remote delegation, specify which data can leave the application and which identity will be used to perform actions. The receiving service must enforce its own controls; a request from the model is not proof of authorization.

Returned content is also external data. A document, tool description, or deliverable can contain misleading instructions. The article on MCP integration and skill security details the checks to perform before installation.

Before expanding access, test a complete workflow that includes an error, a refusal, and an interruption. You should be able to understand what was requested, executed, and transmitted. A protocol standardizes exchanges; control over actions depends on the application that authorizes and checks them.

Frequently asked questions

What does A2A mean for AI agents?

A2A stands for Agent2Agent. This standard describes exchanges between independent agent systems, even when their internal workings remain private. An integration must support the interfaces and capabilities needed for that exchange.

Can you use MCP without the A2A protocol?

Yes. An assistant connected to tools does not need to delegate work to another agent. A2A becomes relevant when a system needs to communicate with an independent agent service. The number of available tools alone does not justify adding it.

Does tool calling require an MCP server?

No. An application can declare its functions directly to the model and execute the calls it receives. MCP provides a common interface for discovering and using external capabilities. The choice depends partly on whether you need to reuse those connections across applications.

Can an A2A-compatible agent access all my tools?

Compatibility does not give an agent unrestricted access to your accounts. Permissions depend on the service, the identity used, and the controls enforced by the server. You also need to review the data included in each delegated request.