Skip to lesson

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 signalMCPA2A
Remote partyTool or resource serverAutonomous remote agent
ContractNamed capability with structured inputs and outputsGoal-oriented collaboration
Control of executionCalling host or agent orchestrates the stepsRemote agent controls its internal execution
Typical interactionDiscrete invocation or context retrievalStateful, multi-turn, or long-running task
Internal implementationCapability is exposed directlyReasoning, 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.

The support agent uses MCP for fixed operations and A2A for autonomous collaborators, while the logistics agent keeps its own MCP toolsStarts at the support agent. It calls the shipment status and refund tools through MCP, and delegates to the billing specialist and the external logistics agent through A2A. Inside the logistics provider's boundary, the logistics agent calls its own carrier and warehouse tools through MCP, so A2A joins the agents and MCP sits inside each agent's tool boundary.External logistics providerMCPA2AA2AMCPLogistics agentCarrier andwarehouse toolsSupport agentShipment statusand refund toolsBilling specialist

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

References