MCP connects an agent to tools; A2A connects agents to peer agents

Details

What each protocol connects

MCP (Model Context Protocol) lets a client application expose tools, resources and prompts from a server to a language model. In the 2026-07-28 spec, tools are called with tools/call and return a typed result. Tools are model-controlled: the caller's model discovers them and chooses when to call them.

A2A is described by its documentation as "an open standard for communication between AI agents". An A2A client is the requesting agent and an A2A server is the remote agent. The docs say agents collaborate "without exposing their internal logic, memory, or proprietary tools".

Where the two meet

                 +------------------+
  user / caller  |   Your agent     |
  ------------->|  (has an LLM)    |
                 +---+----------+---+
                     |          |
          MCP (down) |          | A2A (sideways)
                     v          v
          +----------------+  +------------------+
          | MCP servers    |  | Peer agent       |
          | typed tools    |  | own LLM, own     |
          | and resources  |  | state, multi-turn|
          +----------------+  +------------------+

A2A's own page gives an example: a mechanic agent uses MCP to call a diagnostic scanner and a repair-manual database, and uses A2A to negotiate with a parts supplier's agent.

What the MCP community said

In modelcontextprotocol discussion 1108, opened 2025-04-09 (12 comments, 10 participants when checked), one participant wrote that A2A assumes the remote peer is LLM-enabled while an MCP server typically relies on the caller's LLM. Another listed things MCP lacked at the time, including partial-chunk streaming and asynchronous tool execution. These are participants' views, not spec text.

On asynchronous work: the MCP Tasks extension, named io.modelcontextprotocol/tasks in the 2026-07-28 revision, provides protocol-level handling of long-running tool calls. Its announcement says MCP tool calls were otherwise synchronous. Streaming of partial results is a separate question that this page did not verify.

Tool or agent? A test

This is a heuristic of this wiki, built on the distinctions above, not an official rule.

Question about the remote capability	Yes means
Does it hold a multi-turn conversation?	Agent
Does it decide its own steps with its own model?	Agent
Are its internals opaque to you by design?	Agent
Is it one call with a typed input and a typed result?	Tool
Does it behave the same way every time for the same input?	Tool

Mixed answers usually mean tool. Wrapping an agent in a tool is possible, but then every long conversation becomes one call. Use A2A when the conversation itself is the point.

Worked example

You build a travel assistant. Flight search, calendar lookup and currency conversion are stateless calls with typed results, so they are MCP tools. Negotiating a group booking with an airline's own booking agent is multi-turn and that agent keeps its own state, so that is a peer agent reached over A2A.

Common mistakes

• Treating "MCP vs A2A" as a choice. Most designs need only one, and larger ones use both.
• Exposing a whole agent as one MCP tool and expecting conversation state to persist. MCP 2026-07-28 has no protocol-level session.
• Reaching for A2A when a typed function would do. A tool is simpler to test and secure.
• Copying claims about a shared governing body from search snippets. This page did not confirm them and makes none.