Choose MCP for tools and A2A for agents

Learning objective

Distinguish agent-to-tool (MCP) from agent-to-agent (A2A) protocols.

Core idea

Choose the protocol by what crosses the interface. Model Context Protocol (MCP) exposes tools that a caller discovers and invokes through schemas. Agent2Agent (A2A) exposes a remote agent’s capabilities and a conversation or task through which the caller delegates work. A remote agent can use MCP tools internally; the protocols solve different parts of the same system.

The deciding distinction is responsibility. With a tool interface, the caller selects an operation and supplies its arguments. With an agent interface, the caller delegates an outcome to a service that can manage its own execution and exchange task progress and results. Neither a network connection nor the presence of an LLM inside the service settles the choice.

How it works

Inspect the operation the caller invokes

An MCP server advertises its tools capability and answers tools/list with tool definitions. Each definition names the tool and its inputSchema; the client invokes it through tools/call, supplying name and arguments. The schema establishes what the caller can request. It does not establish whether the underlying operation is safe for a particular user or whether a returned answer is correct.

For example, a retrieval tool might accept a query and return document excerpts. The calling agent decides whether retrieval is the next useful action and how to use those excerpts. Even if the implementation performs several internal steps, its external interface remains a tool call. MCP also has other capabilities; describing it as a tool protocol here identifies the objective’s boundary, not its entire specification.

A2A publishes an AgentCard containing skills, supported interfaces, media types, and security requirements. A caller sends a Message through SendMessage; the remote agent can return a direct Message or a Task. The task has an identifier, status, and potentially output Artifact objects. This gives a caller vocabulary for delegated work beyond a single operation’s return value. See 1.3.2 for discovery and result handling.

A skill description is not an MCP inputSchema. It describes a focused ability of the remote agent. Do not assume that discovering a skill creates a separately addressable RPC method with that skill’s name. The A2A interaction carries messages to the agent, which owns how it fulfills the request.

Recognize both integrations in NeMo Agent Toolkit

NeMo Agent Toolkit connects to MCP servers through function_groups with _type: mcp_client. Its server section supplies the transport and endpoint, such as transport: streamable-http and url. The group discovers remote tools and registers them as toolkit functions. A workflow can expose the group through tool_names; the toolkit documentation also describes selecting individual imported functions.

The A2A integration uses function_groups with _type: a2a_client and a remote-agent url. It discovers the Agent Card and exposes several API levels: agent_name.call(query) for natural-language delegation, helpers such as get_task(), and low-level send_message() and send_message_streaming() access. Install the relevant optional package through nvidia-nat[mcp] or nvidia-nat[a2a]; neither integration should be assumed present from a package name alone.

The A2A client documentation requires a per-user workflow because clients have per-user connection, authentication, and session state. Its configuration example uses _type: per_user_react_agent. This is an integration requirement, not a general claim that all A2A servers or all agent frameworks use the same state model.

Both integrations can therefore appear as functions to the calling workflow. That local representation does not change the wire protocol or transfer the remote agent’s internal planning into the caller. An agent-as-a-tool pattern is compatible with A2A; the phrase describes how the caller composes it (see 1.5.1).

Key distinctions and trade-offs

The following questions distinguish the interfaces:

A schema-oriented tool is a good fit for a stable operation such as looking up a shipment. Delegation is useful when another team owns a specialist agent’s multi-turn interaction through contextId, taskId, and TASK_STATE_INPUT_REQUIRED, and delivers its results as Artifact outputs. A2A introduces task-state and result-consumption responsibilities; do not pay that integration cost merely because a tool runs on another host.

MCP tools can also request input: tools/call can return an InputRequiredResult with resultType: "input_required" and inputRequests. Long-running tool work can use the io.modelcontextprotocol/tasks extension. “MCP is synchronous; A2A is asynchronous” is therefore an unreliable definition, and A2A also permits direct message responses. Decide from the advertised interface and capabilities rather than assuming a duration or execution mode from the protocol name.

Architecture / decision scenario

A retailer builds an employee assistant with a 2-second target for stock lookups and a 90-second allowance for investigating delayed deliveries. The warehouse team owns an exact lookup_stock operation with a fixed argument schema. A logistics team owns an investigation agent that consults carriers, requests missing shipment details, and returns a report.

One proposal exposes both services as agents because both are remote. Another wraps both as ordinary lookup tools to keep one client style. The application architect chooses MCP for the stock operation and A2A for the investigation. The first proposal adds task handling to a bounded lookup; the second hides the specialist agent’s task and artifact model behind a single lookup.

The assistant imports stock operations with mcp_client and delegates investigations through a2a_client. A remote logistics agent may itself use MCP to call carrier tools. The logistics team owns investigation completion and artifacts; the assistant team owns presenting that state and enforcing its caller’s time budget. These are scenario targets, not protocol latency guarantees.

Common exam traps

• Choosing A2A solely because a service is remote or implemented with an LLM.
• Treating an Agent Card skill as a schema-defined MCP operation.
• Assuming a toolkit function wrapper makes the underlying protocol MCP.
• Equating MCP with synchronous work and A2A with asynchronous work.
• Assuming discovery also authorizes invocation.

Where the exam guide differs

What to remember

Use MCP to expose and invoke operations; use A2A to delegate work to a remote agent and exchange its replies or task results. One system can use both. Inspect the actual discovery objects, invocation shape, and execution responsibility before choosing the interface.

Knowledge check

References

• Model Context Protocol, Tools
• Model Context Protocol, Key Changes
• A2A Project, A2A Protocol Specification v1.0.0
• A2A Project, Release v1.0.0
• NVIDIA, NVIDIA NeMo Agent Toolkit as an MCP Client
• NVIDIA, NVIDIA NeMo Agent Toolkit Workflow as an A2A Client
• NVIDIA, NVIDIA-Certified Professional: Agentic AI Exam Study Guide