Use MCP when the remote party is a capability
An MCP server exposes structured primitives to a host. The host can discover tools, resources, and prompts and route model-selected operations to the server. The server is not required to be an autonomous collaborator with its own public task lifecycle or skills card.
Use A2A when the remote party is an agent
A2A is designed for independent, potentially opaque agent systems to discover capabilities, exchange messages and artifacts, and coordinate synchronous or long-running tasks. The receiving agent can retain control of its internal model, memory, tools, and workflow while exposing a collaboration interface.
The same delegated task looks different
With MCP, the host discovers a tool schema and calls the operation with structured arguments, then receives tool content. With A2A, an orchestrator discovers an Agent Card, sends a message or creates a task, follows status or streaming updates, and receives artifacts. One is capability invocation; the other is delegated work coordination.
Use both without collapsing the trust boundaries
An orchestrator can delegate research to a specialist over A2A. That specialist can use MCP servers for search, files, or databases, then return an artifact over A2A. Authenticate and authorize both boundaries, propagate only the minimum user context, and preserve correlation IDs without forwarding credentials meant for another resource.
Decide with a non-goals checklist
Do not add A2A merely to call a deterministic function, and do not stretch an MCP tool call into a public multi-agent task protocol. Ask whether the remote party owns a task lifecycle, can negotiate modalities, and returns artifacts as an agent. If not, MCP or a regular API may be the simpler fit.