Google CloudProfessional Agentic Architect2026-093.3 Orchestrating and coordinating agentic workflows
Choose between MCP and A2A
Completed by the knowledge check
Learning objective
Choose Model Context Protocol (MCP) for agent-to-tool interaction and Agent2Agent (A2A) Protocol for autonomous agent-to-agent collaboration. This lesson focuses on selecting the protocol boundary, not on implementing either protocol or designing a multiagent workflow.
Core idea
Classify the other party by its contract, not by where it runs or how it is built:
- Choose MCP when your agent needs a bounded capability and remains responsible for deciding how that capability fits into its plan.
- Choose A2A when your agent delegates a goal to another autonomous agent, which decides how to pursue that goal and collaborates over the result.
In short, MCP is for using capabilities; A2A is for delegating outcomes. The protocols are complementary. One agent can collaborate with another through A2A while each agent uses its own tools through MCP. The official A2A and MCP comparison describes this as MCP giving an agent depth and A2A giving an agentic system reach.
How it works
With MCP, a host application manages MCP clients and connects each client to a server. The server exposes focused primitives such as tools, resources, and prompts. For tool use, the agent selects a schema-defined operation, supplies arguments, and receives a result. The host retains orchestration and security responsibilities. See the MCP architecture specification.
Examples of MCP-shaped requests include:
- look up a shipment by tracking number;
- query an approved data source;
- create a ticket with validated fields;
- calculate tax for a supplied order.
With A2A, a client agent communicates with a remote agent as an independent problem solver. The remote agent can hide its model, memory, plan, and tools. It publishes capabilities, accepts messages, manages tasks, and can exchange updates and results during long-running or multi-turn work. The A2A specification defines interoperability between independent, potentially opaque agentic systems without requiring them to share internal state or tools.
Examples of A2A-shaped requests include:
- investigate a disputed invoice and propose a resolution;
- plan a shipment across several carriers and constraints;
- ask a legal-review agent to assess a contract change;
- coordinate with a partner’s procurement agent to source a part.
Ask this diagnostic question: Does the caller prescribe the operation, or delegate the problem? A prescribed operation points to MCP. A delegated problem that requires independent reasoning, planning, or negotiation points to A2A.
Key distinctions and trade-offs
| Decision signal | MCP | A2A |
|---|---|---|
| Remote party | Tool or resource server | Autonomous remote agent |
| Contract | Named capability with structured inputs and outputs | Goal-oriented collaboration |
| Control of execution | Calling host or agent orchestrates the steps | Remote agent controls its internal execution |
| Typical interaction | Discrete invocation or context retrieval | Stateful, multi-turn, or long-running task |
| Internal implementation | Capability is exposed directly | Reasoning, memory, and tools can remain opaque |
These signals describe the boundary, not strict implementation tests. A remote service can still be an MCP server. Two agents in the same runtime can still need an A2A-style collaboration boundary. Network location, vendor, model, and framework do not determine the protocol.
MCP usually gives the caller tighter control and a smaller interface. It fits operations that need predictable schemas, validation, and narrow permissions. A2A preserves the remote agent’s autonomy and supports richer coordination, but it adds discovery, task state, conversation, and lifecycle concerns. Do not pay that coordination cost for a calculator or a fixed database lookup.
An autonomous implementation can be exposed as an MCP tool when the boundary is deliberately narrow. For example, classify_claim can hide an agent internally but still behave as one bounded operation. Conversely, naming an API endpoint an “agent” does not make A2A appropriate if it only performs fixed commands.
Neither protocol creates trust. Authentication, authorization, input validation, approval, data handling, and audit controls still apply at each boundary.
Architecture / decision scenario
A retail support agent must check delivery data, resolve billing disputes, and arrange replacement shipments with an external logistics provider.
The delivery system offers get_shipment_status with a tracking-number schema. The support agent knows when to call it and how to use the result, so the team exposes it as an MCP tool. A deterministic refund API is also exposed through a narrow MCP tool with an approval control.
Billing disputes are different. A specialist agent gathers evidence, applies account policy, requests missing details, and returns a reasoned resolution. The support agent delegates the outcome instead of prescribing each step, so the team connects to that specialist through A2A.
The external logistics agent can negotiate dates, carriers, and capacity over several turns. It also uses private planning logic and its own carrier tools. The support agent therefore uses A2A to request a replacement shipment. Inside the logistics boundary, that agent can use MCP to call carrier and warehouse tools.
So the support agent uses MCP for its fixed operations and A2A for its autonomous collaborators, while the logistics agent keeps its own MCP tools inside its boundary.
This design avoids two opposite mistakes: pretending autonomous collaborators are single tool calls, and turning every fixed operation into a multiagent conversation.
Common exam traps
- Choosing A2A merely because a service is remote or owned by another team.
- Choosing MCP merely because the remote system uses an LLM internally.
- Treating MCP and A2A as competing protocols when one architecture can use both at different boundaries.
- Using A2A for a fixed, schema-defined operation that does not require autonomous collaboration.
- Wrapping a goal-seeking agent as one MCP tool and then expecting standard MCP tool semantics to provide negotiation and agent task coordination.
- Assuming either protocol supplies authorization, least privilege, approval, or policy enforcement by itself.
What to remember
- Choose by contract: bounded capability or delegated outcome.
- Use MCP when the caller orchestrates a tool or resource interaction.
- Use A2A when an independent agent owns how to pursue a delegated goal.
- Topology, framework, vendor, and use of an LLM do not decide the protocol.
- Combine A2A between agents with MCP inside each agent’s tool boundary.
Knowledge check
A remote service uses an LLM internally but exposes only classify_claim with a fixed input schema and one result. The caller owns the overall plan. Which boundary fits?
A partner agent must negotiate a delivery plan, request missing information, and choose its own carrier tools without exposing its implementation. Which boundary fits?
References
- A2A Protocol, A2A and MCP: Detailed comparison
- A2A Protocol, Agent2Agent Protocol specification
- A2A Protocol, Core concepts and components
- Model Context Protocol, Architecture
- Model Context Protocol, Tools