MCP vs A2A: Differences, Architecture, and When to Use Each Protocol

MCP vs A2A: the short answer

MCP standardizes access to capabilities; A2A standardizes delegation to independent agents. Use MCP when an application needs to call a tool or read data from another system. Use A2A when a caller should message another agent, let that agent own its execution plan, track agent work, and receive Messages or Artifacts. Use both when agents collaborate through A2A and each agent reaches its own tools and data through MCP. [S340] [S054] [S339]

For example, an application might call an MCP tool to fetch an invoice. With A2A, it could ask a billing agent to investigate a disputed invoice and let that agent decide which records and tools to use. The choice depends on who should plan the work.

MCP vs A2A at a glance

Table 1: MCP vs A2A at a glance comparison

Dimension	MCP	A2A
Primary boundary	AI application or agent to capability provider	Client agent to remote agent
Caller intent	Invoke or retrieve a bounded capability	Delegate a goal, request or collaborative unit of work
Typical remote component	Focused server wrapping tools, data, APIs or local code	Opaque agent application that may plan and use its own tools
Core discovery	server/discover plus tools/resources/prompts list methods	Agent Card, usually at /.well-known/agent-card.json or through registry/configuration
Capability unit	Tool, resource, prompt or extension	Agent skill advertised in an Agent Card
Long-running work	Optional Tasks extension	Task is a core protocol object
Durable output	Tool/resource result; task result under extension	Artifacts attached to a Task
Local deployment	Common through stdio	Can connect local agents, but A2A does not define MCP's standardized subprocess/stdio binding.
Network bindings	stdio and Streamable HTTP in current core	JSON-RPC, HTTP+JSON/REST and gRPC; custom bindings permitted
Authorization model	Detailed OAuth resource-server profile for remote MCP	Web-security schemes declared in Agent Card; credentials out of message body
Version form	Date-based core revisions such as 2026-07-28	Major.minor compatibility such as 1.0; patch tags identify specification releases but are not negotiated.
Best fit	Reusable bounded tools, data and interaction surfaces	Cross-agent delegation, collaboration and long-running agent work

The table compares protocol roles, not product size or intelligence. Neither protocol automatically establishes trust, authorization, correctness, or safety. [S339] [S340] [S054]

---

Capability invocation versus outcome delegation

What MCP solves

Before MCP, AI products commonly built integrations as application-specific adapters. One host might implement its own GitHub connector, another its own database wrapper, and a third its own filesystem interface. The same external capability could require repeated schemas, authentication logic, execution code and product-specific packaging.

MCP addresses that fragmentation by defining a reusable server boundary. A compatible host can connect through an MCP client, discover capabilities and invoke them without embedding the entire integration inside the host. The underlying MCP server may call REST or GraphQL APIs, query a database, execute local code, use a software SDK or interact with the filesystem. MCP does not replace those systems; it gives AI applications a common way to reach them. [S021] [S121] [S123]

The current MCP architecture has four important properties.

1. Capability orientation. Servers publish tools, resources, prompts and extensions rather than advertising themselves primarily as autonomous collaborators. [S123] [S124] [S125] [S318]
2. Host control. The host determines which capabilities become visible to the model, how results enter context and when the user must approve an action. [S121]
3. Local and remote deployment. stdio supports locally launched subprocesses; Streamable HTTP supports remote services. [S057]
4. Stateless core. In 2026-07-28, requests carry protocol version, client information and relevant capabilities instead of relying on an initialization handshake and hidden protocol session. [S055] [S056]

A simplified MCP flow is:

User
  ↓
MCP host and model
  ↓
MCP client
  ↓
MCP server
  ↓
API, database, filesystem, SDK, CLI or local code

The model normally does not open the MCP connection itself. The host translates server capabilities into whatever interface the model provider uses, mediates selection and permission, and sends the actual MCP request through the client.

What A2A solves

A2A addresses a different fragmentation problem: independent agents built by different teams, vendors or frameworks need a way to discover one another, communicate and coordinate work without exposing their internals. Google publicly introduced A2A in April 2025, then contributed it to the Linux Foundation in June 2025. The project later released v1.0 as its first stable production-ready line in March 2026 and joined the Agentic AI Foundation in August 2026. [S118] [S353] [S338] [S355]

A2A treats the remote agent as an opaque service. The client can learn what it claims to do through an Agent Card, but it does not need access to the remote agent’s model prompt, memory, framework, internal tools or execution plan. The client sends a Message, and the remote agent may answer directly or create a Task whose progress and outputs can be observed. [S337] [S339] [S341]

A simplified A2A flow is:

User or coordinator
  ↓
Client agent
  ↓ A2A
Remote specialist agent
  ├── internal model and memory
  ├── internal workflow
  ├── MCP tools or direct APIs
  └── human or system interactions
  ↓
Message, Task updates and Artifacts

A2A’s v1.0 specification uses a normative Protocol Buffers data model and defines three protocol bindings: JSON-RPC, HTTP+JSON/REST and gRPC. It supports direct messages, tracked Tasks, streaming, polling and push notifications. [S339] [S348] [S384] [S385]

The boundary is responsibility, not complexity

The most reliable way to choose between MCP and A2A is to ask what responsibility crosses the boundary.

MCP: invoke a bounded capability

With MCP, the caller usually knows the operation it wants to invoke. A tool named create_issue, query_database or fetch_document has an input contract. The server may be sophisticated internally, but the interaction is framed as a capability call. The host remains responsible for deciding how that call fits into the larger user task. [S123]

A2A: delegate a desired outcome

With A2A, the caller can communicate a goal such as “investigate this production incident,” “prepare a compliant travel itinerary” or “review this codebase for security risks.” The remote agent may decide which internal methods, tools, sub-agents and human interactions are required. It may return progress updates and several Artifacts rather than one function-shaped result. [S341] [S343] [S344]

The boundary is a spectrum

Not every real system fits perfectly at one end.

• An MCP tool can trigger a complex workflow.
• An A2A agent can expose a narrow deterministic skill.
• An MCP server can call an A2A agent behind the scenes.
• An A2A agent can expose MCP tools to callers.
• A coordinator can use native function calling, MCP and A2A in one execution graph.

The question is not whether the implementation is “agentic” in marketing language. The question is whether the caller is invoking a defined capability or delegating responsibility to an independently operated agent.

---

MCP tools versus A2A skills

The tool-versus-skill distinction is central because superficial comparisons often treat both as lists of callable functions.

MCP tool

A current MCP tool has a name, descriptive metadata and an inputSchema. It can also provide an outputSchema, icons and annotations. A client obtains tools through tools/list and calls one through tools/call. Results may include text, images, audio, structured content, embedded resources or resource links. [S123]

A tool definition is suited to bounded operations:

create_issue(owner, repository, title, body)
search_logs(query, start_time, end_time)
get_customer(customer_id)
run_build(project, branch)

The host may let a model select among tools, but the host remains responsible for exposing, filtering and authorizing them.

A2A skill

An A2A skill is metadata inside an Agent Card. It describes something the remote agent can do, often with human-readable examples, tags and supported input/output modes. It helps the client decide whether to contact the agent. It is not necessarily the exact method subsequently invoked. The actual interaction normally proceeds through Messages and, when needed, Tasks. [S339] [S341]

A skill may be broader:

Investigate distributed-system incidents
Plan international corporate travel
Review software for regulatory compliance
Negotiate purchasing options with approved suppliers
Prepare a migration plan and coordinate execution

One skill may internally use dozens of tools, several models, a human approval step and multiple external systems.

Comparison

Table 2: Comparison comparison

Dimension	MCP tool	A2A skill
Granularity	Usually operation-shaped	Often outcome- or domain-shaped
Invocation	tools/call with structured arguments	Send a Message; agent may answer or create a Task
Schema	JSON Schema input contract	Descriptive metadata and modes; inputs arrive as Message Parts
Execution discretion	Usually bounded by operation	Potentially broad
Discovery	Runtime tool listing	Agent Card
Result	Tool result content or Task extension handle	Message or Task with Artifacts
Internal implementation	Hidden but expected to implement the tool contract	Deliberately opaque and agent-owned
Best question	“What operation should run?”	“Which agent can own this outcome?”

Why a skill is not just a large tool

A giant tool definition such as solve_business_problem(problem, context) may technically invoke an agent through MCP. But it can conceal several semantics that A2A makes explicit:

• durable Task identity;
• task-state transitions;
• agent-oriented discovery;
• output Artifacts;
• continued interaction;
• push notifications;
• the remote party’s independent identity and interfaces.

Conversely, wrapping a deterministic currency-conversion function as an A2A agent introduces a heavier task and identity model where a simple tool or API would be clearer.

Table 3: Why a skill is not just a large tool comparison

Term	What it describes	What it does not establish
A2A AgentSkill	Capability metadata in an agent's card.	A portable directory of workflow instructions.
Agent Skills package	A SKILL.md file with instructions and optional supporting files.	How a remote host discovers or retrieves it.
MCP Skills extension	Discovery and retrieval of Agent Skills through MCP Resources.	That a host will activate the skill or authorize its actions.

For implementation, client support and a reproducible integrity check, see Skills over MCP.

The tools, resources and prompts guide explains how to expose an operation, a document or a message template.

---

MCP discovery versus A2A Agent Cards

MCP and A2A both need discovery, but they discover different things.

MCP discovery

Under MCP 2026-07-28, server/discover lets a client learn supported protocol versions and high-level capabilities before invoking another method. Servers MUST implement the method. Calling it as a client preflight is optional because a client may instead invoke another RPC directly and handle an unsupported-version error. After that, clients use methods such as tools/list, resources/list, resources/templates/list and prompts/list to enumerate detailed capabilities. [S127] [S123] [S124] [S125]

MCP discovery is therefore layered:

server/discover
  ↓
protocol versions and high-level server capabilities
  ↓
tools/list, resources/list, prompts/list
  ↓
concrete capabilities

A current MCP server may also participate in package registries, private catalogs, enterprise gateways or host-specific installation systems, but those distribution mechanisms are not the same as core runtime discovery.

A2A Agent Cards

An Agent Card describes an agent as a network service. The v1.0 data model can include:

• name and description;
• provider and documentation metadata;
• advertised interfaces;
• protocol binding and version;
• capabilities;
• default input and output modes;
• skills;
• security schemes and requirements;
• optional signatures. [S339] [S342]

A public Agent Card is commonly retrievable from:

/.well-known/agent-card.json

The use of a well-known URI follows the general web convention standardized by RFC 8615. A2A can also support direct configuration, registries and authenticated extended Agent Cards containing more sensitive metadata. [S342] [S379]

Agent Card signatures

A2A allows optional Agent Card signatures based on JWS and canonicalized JSON. This can help a client verify that the card came from an expected signer and has not been altered. It cannot prove that the agent is competent, honest, correctly authorized or safe. Cryptographic provenance is one input to trust, not a substitute for policy and operational evidence. [S339] [S380] [S381]

Discovery comparison

Table 4: Discovery comparison comparison

Question	MCP	A2A
What is discovered?	Server protocol support and capabilities	Agent identity, interfaces, security and skills
Primary object	DiscoverResult plus primitive listings	AgentCard
Standard public path	None in current core	/.well-known/agent-card.json
Protocol versions	supportedVersions	Interface-level protocol version
Detailed executable surface	Tool/resource/prompt list methods	Skills describe agent abilities; interaction uses Messages/Tasks
Security metadata	MCP authorization and protected-resource metadata	Agent Card security schemes and requirements
Optional signed description	No equivalent general core server-card signature	JWS signatures supported
Trust conclusion	Server claims capabilities	Agent claims identity and skills

Neither form of discovery is proof. A malicious MCP server can lie about a tool, and a malicious A2A endpoint can misrepresent a skill.

---

MCP Tasks versus A2A Tasks

The shared term Task creates the most serious terminology trap in this comparison.

A2A Task: core tracked agent work

A2A defines Task as a central protocol object. A Task has an identifier, status, history and Artifacts. The v1.0 state model includes:

• unspecified;
• submitted;
• working;
• completed;
• failed;
• canceled;
• input_required;
• rejected;
• auth_required. [S339] [S343]

A client can retrieve, list, cancel and subscribe to Tasks. Work can be handled synchronously, streamed, polled later or observed through push notifications. A contextId can group related Messages and Tasks. [S339] [S344]

The A2A Task is therefore an explicit record of delegated agent work. Its state survives individual HTTP exchanges, and the server can publish interim status or Artifact updates while retaining internal execution freedom.

MCP Task: extension execution mode for an MCP request

MCP Tasks began as experimental core functionality in 2025-11-25 and were reworked into an official extension for 2026-07-28. A client and server must explicitly negotiate the io.modelcontextprotocol/tasks extension. A server handling a supported request may return a Task handle rather than the normal immediate result. [S050] [S137]

Current MCP Task states are:

• working;
• input_required;
• completed;
• failed;
• cancelled. [S137]

The principal methods include tasks/get, tasks/update and tasks/cancel. Current MCP Tasks do not define a general tasks/list. Updates can be delivered through requested subscription streams. Cancellation is cooperative and may not stop underlying work immediately. [S137]

Side-by-side comparison

Table 5: Side-by-side comparison comparison

Dimension	MCP Tasks	A2A Tasks
Status in protocol	Optional official extension	Core protocol object
Typical trigger	Long-running execution of an MCP request	Delegated agent work requiring tracking
Creation	Server replaces normal result with Task handle after opt-in	Agent returns a Task instead of direct Message
Identifier	taskId	Task id
Context grouping	Application-defined handles; no equivalent core conversation grouping	contextId groups related work
States	Five current states	Nine defined values including submitted, rejected and auth-required
Listing	No general tasks/list	List Tasks is core
Polling	tasks/get	Get Task
Update/input	input_required and tasks/update flow	Follow-up Messages and explicit task states
Cancellation	tasks/cancel, cooperative	Cancel Task operation
Streaming	Subscription notifications where negotiated	Core streaming and task event methods
Push notifications	Not a general core webhook system	Core push-notification configuration
Result	Original MCP result or error	Artifacts, history and final status
Primary meaning	Durable execution mode for one MCP request	Unit of agent collaboration and delegated work

Why an adapter is required

A platform that exposes one unified “Task” API over MCP and A2A must decide how to translate:

• state names and spelling (cancelled versus canceled);
• submitted and rejected states absent from MCP Tasks;
• A2A auth_required versus MCP input/authorization flows;
• Artifact updates versus MCP result content;
• Task listing;
• push notifications;
• context grouping;
• retention, history and expiry.

A shared dashboard can display both, but the system should preserve the originating protocol and native identifiers. Flattening the models too aggressively discards operational meaning.

An adapter can translate selected states, but the mapping is deliberately lossy: A2A includes states such as submitted, rejected, and auth_required, plus history and Artifacts, while MCP Tasks remains an execution mode for a supported MCP request. Download the nine-row state map or its CSV edition.

---

Transport, authorization, security, and governance

Transport and delivery

MCP and A2A both use familiar internet technologies, but their transport portfolios reflect different deployment histories.

MCP transports

Current MCP defines two principal transports:

• stdio, in which a client launches or connects to a local process and exchanges messages over standard input and output;
• Streamable HTTP, a remote HTTP transport that can return ordinary JSON or SSE streams where streaming is required. [S057]

MCP’s message model is based on JSON-RPC 2.0. The current HTTP form adds MCP-specific headers for versioning and infrastructure routing. [S054] [S001]

stdio is historically significant because it lets a host install and run a small local server without deploying a network service. That makes MCP suitable for filesystem access, developer tools and local automation, but it also creates package-trust and local-code-execution risks.

A2A bindings

A2A v1.0 defines a normative Protocol Buffers data model and three official bindings:

1. JSON-RPC;
2. HTTP+JSON/REST;
3. gRPC. [S339] [S348] [S384] [S385]

Bindings map the common model and operations into different transport conventions. A2A also provides guidance for custom protocol bindings. An Agent Card’s supported interfaces can identify endpoint URL, binding and protocol version. [S339] [S347]

Streaming and asynchronous delivery

Both protocols can use SSE, but “uses SSE” does not mean they have the same architecture.

• MCP can use SSE for streamed HTTP responses and requested notification streams. [S057]
• A2A can stream Message and Task events and also supports polling and push-notification delivery. [S344]

A2A’s push model introduces webhook-specific security questions: callback authentication, SSRF prevention, endpoint validation, replay protection and tenant binding. MCP’s current core does not define an equivalent general-purpose webhook system.

Transport matrix

Table 6: Transport matrix comparison

Property	MCP	A2A
Local subprocess	First-class stdio	Not a central standard binding
Remote HTTP	Streamable HTTP	JSON-RPC or HTTP+JSON/REST
gRPC	Not a core MCP transport	Official binding
Canonical data model	JSON-RPC-based TypeScript/JSON schemas	Normative Protocol Buffers model
SSE	Response and subscription streaming	Agent/Task streaming
Polling	Repeated methods; Tasks extension	Core Get Task
Webhooks	No general core mechanism	Core push-notification support
Custom bindings	Extensions can add behavior; core transports are limited	Specification provides custom-binding guidance

Which is simpler?

Neither is universally simpler.

• A small local MCP stdio server can be extremely simple.
• A production remote MCP server with OAuth, multi-tenancy and policy can be complex.
• A direct A2A Message exchange can be simple.
• A cross-organization A2A deployment with signed Agent Cards, push notifications, durable Tasks and delegated identity can be complex.

Protocol choice should follow the interaction contract, not an assumption that one transport stack is inherently lighter.

Authentication, authorization, and identity

Security is where “MCP for tools, A2A for agents” becomes operationally consequential.

MCP authorization model

For remote deployments, MCP defines an OAuth-oriented relationship in which the MCP server acts as a resource server. The current specification includes protected-resource metadata, authorization-server discovery, client identification and resource/audience binding requirements. Authorization remains separate from user confirmation inside the host. [S133] [S003]

An MCP server must still enforce:

• user and tenant identity;
• tool-specific permission;
• object-level authorization;
• least privilege in upstream APIs;
• semantic validation;
• safe token handling.

The fact that a user approved a model tool call does not grant access to a forbidden repository, another tenant’s database row or an unapproved filesystem path.

A2A security metadata

An Agent Card can advertise security schemes and security requirements using web-oriented structures. Credentials are acquired through the applicable security mechanism rather than embedded in an Agent Card. The A2A server remains responsible for authenticating the caller and authorizing access to agents, skills, Tasks and Artifacts. [S339] [S345] [S386]

A2A also has to reason about several identities:

• the client application;
• the calling agent;
• the end user;
• the remote agent;
• the organization operating each agent;
• downstream tools and services;
• callback endpoints;
• the owner of a Task or Artifact.

Agent Card identity is not behavioral proof

Provider metadata and a signed Agent Card can help establish who published the card. They do not establish:

• that the agent will perform the advertised skill well;
• that every action is authorized;
• that outputs are truthful;
• that internal tools are secure;
• that the endpoint has not been compromised;
• that the agent will not mishandle sensitive data.

Delegation and authority

A2A creates an explicit delegation boundary. A client agent may ask a remote agent to achieve an outcome, but the remote agent’s authority should be bounded. A secure design answers:

1. Whose identity is presented to the remote agent?
2. Is the remote agent acting as the user, the client agent or a service account?
3. Which downstream systems may it access?
4. Can it delegate again?
5. How is the original user’s purpose preserved?
6. How are approvals and policy decisions recorded?
7. Can authorization be re-evaluated during a long Task?

MCP has analogous questions for tool access, but A2A can amplify them because the remote agent may choose a plan and several downstream actions.

Threats across a combined stack

MCP-specific or MCP-prominent risks

• malicious local server packages;
• tool poisoning and misleading descriptions;
• over-privileged tools;
• prompt injection through resources or results;
• unsafe argument handling;
• OAuth implementation errors;
• filesystem and command execution;
• supply-chain compromise;
• host confirmation failures.

A2A-specific or A2A-prominent risks

• agent impersonation;
• forged, stale or misleading Agent Cards;
• skill misrepresentation;
• authority escalation through delegation;
• Task or Artifact access-control failures;
• malicious push-notification endpoints;
• cross-tenant Task leakage;
• long-running credential expiry;
• opaque downstream actions;
• artifact poisoning.

Risks in a combined stack

A combined A2A–MCP system creates additional failure paths:

Untrusted A2A Message
  ↓
Remote agent reasoning
  ↓
High-authority MCP tool
  ↓
Enterprise system

or:

Malicious MCP resource
  ↓
Specialist agent
  ↓ A2A
Coordinator agent
  ↓
Another agent or tool boundary

The most important combined risks are:

• identity loss: the downstream MCP server sees only the specialist agent’s service identity;
• purpose loss: the original user’s intended purpose is not preserved;
• authority amplification: an agent with broad MCP tools acts on an untrusted Message;
• provenance loss: Artifacts or tool results are forwarded without source labels;
• audit fragmentation: no system records the complete A2A and MCP chain;
• confused delegation: a downstream component assumes the upstream agent already authorized an action.

Security control matrix

Table 7: Security control matrix comparison

Control	MCP boundary	A2A boundary	Combined requirement
Authentication	Identify client/user	Identify client agent/user	Bind identities across protocols
Authorization	Tool/resource/object policy	Agent/skill/Task/Artifact policy	Preserve least privilege end to end
Consent	Host confirmation	User or policy approval for delegation	Distinguish approval to delegate from approval to execute
Provenance	Label server and result source	Label agent, Task and Artifact source	Carry lineage across bridges
Audit	Record tool invocation and upstream action	Record Message, Task transitions and Artifacts	Correlate with one trace/delegation ID
Injection defense	Treat descriptions, resources and results as untrusted	Treat Messages and Artifacts as untrusted	Prevent cross-boundary instruction laundering
Tenant isolation	Server and cache scopes	Agent interfaces, Tasks and Artifacts	Keep tenant context immutable across adapters

Neither protocol automatically supplies the whole end-to-end control plane.

Separate governance under a shared foundation

MCP governance

Anthropic introduced MCP publicly in November 2024. The project later formalized maintainers, Core Maintainers, Working Groups and the SEP proposal process. In December 2025, MCP became a founding project of the Agentic AI Foundation. [S021] [S069] [S070]

MCP continues to use its own repositories, dated specification revisions, maintainers and extension process. Its presence under AAIF does not turn every AAIF project into one protocol or one governance body.

A2A governance

Google introduced A2A publicly in April 2025 and donated the project to the Linux Foundation in June 2025. A2A has its own governance file and an eight-seat Technical Steering Committee representing AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow. [S118] [S353] [S354]

A2A joined AAIF as a hosted project in August 2026. That move places A2A within the same broader open-agent ecosystem as MCP while retaining distinct technical governance. [S355] [S356]

Is either an official internet standard?

As of the verification date, neither MCP nor A2A is an IETF, W3C, ISO or IEC standard. Both are openly published protocols and open-source projects with public contribution processes. “Open standard” should be used carefully: it can describe an open specification and governance effort, but it should not imply formal adoption by a traditional standards body.

Shared foundation does not mean merger

MCP and A2A sharing AAIF matters institutionally. It can encourage neutral stewardship, cross-project coordination and a coherent open-agent stack. It does not mean:

• A2A is an MCP extension;
• MCP is a subset of A2A;
• one TSC controls both;
• their Tasks are compatible;
• their roadmaps will necessarily converge.

---

How MCP and A2A work together

The most important production pattern is not choosing one protocol for an entire system. It is assigning each boundary to the protocol that best describes the relationship.

Layered reference architecture

User
  ↓
Coordinator agent
  ├── native model function calling
  ├── MCP client → enterprise search server
  ├── MCP client → calendar server
  └── A2A client → specialist agent
                       ├── internal planning
                       ├── MCP client → database server
                       ├── MCP client → repository server
                       └── A2A client → another approved agent

In this architecture:

• native function calling helps each model express structured actions;
• MCP gives agents reusable access to capabilities;
• A2A lets agents delegate outcomes to other independently operated agents;
• underlying APIs and databases still enforce their own authorization.

This layered interpretation is consistent with the official A2A comparison material and current foundation positioning. [S340] [S356]

What must cross the bridge

An A2A-to-MCP bridge needs more than a function that copies fields. It should preserve:

1. Principal identity. Who is the end user, calling agent and remote agent?
2. Tenant identity. Which organization and account does the request belong to?
3. Delegation purpose. Why was authority delegated?
4. Scope. Which tools, resources and objects are permitted?
5. Approval status. What did the user or policy actually approve?
6. Provenance. Which Message, Task or Artifact caused an MCP call?
7. Trace context. How can operators correlate the full path?
8. Data classification. May results be returned across the agent boundary?
9. Expiry. Does the delegation remain valid throughout a long-running Task?
10. Revocation. What happens if access is withdrawn while work continues?

Neither protocol defines a universal envelope carrying every one of these properties end to end. A secure platform must design that bridge explicitly.

A common enterprise pattern is a coordinator delegating a goal to a specialist agent over A2A while each agent uses MCP for repositories, databases, calendars, ticketing systems, or approved operational tools. The bridge must preserve user, tenant, purpose, expiry, provenance, and audit context; neither protocol automatically carries a complete authorization chain through the other. [S345] [S356] [S133]

The combined reference-architecture dataset, threat model, and 20-control security checklist provide examples and checks for implementing that combination.

---

Boundary edge cases

Can an agent be exposed through MCP?

Yes. An agent can publish one or more MCP tools. For example:

research_topic(topic, constraints) → report
review_code(repository, revision) → findings
plan_trip(destination, dates, preferences) → itinerary

This can be appropriate when the caller wants a bounded operation and does not need the full A2A lifecycle. It can also make an agent available to MCP-only hosts.

However, the façade may omit:

• Agent Card discovery;
• broad skills;
• agent identity and provider metadata;
• Task listing and history;
• Artifacts as first-class outputs;
• push notifications;
• multi-interface advertisement;
• explicit context grouping;
• the semantic signal that responsibility is being delegated.

An MCP Task can preserve long-running execution, but that still does not make the interaction wire-compatible with A2A.

When the MCP façade is a good fit

Use a façade when:

• the agent exposes a small, stable operation surface;
• the host should retain orchestration;
• one call and one result are the main user experience;
• MCP client reach is more important than agent-to-agent semantics;
• the agent is an internal implementation detail.

When it is a poor fit

Prefer A2A when:

• the remote party advertises multiple broad skills;
• the caller delegates outcomes rather than operations;
• Task history, Artifacts or push delivery matter;
• the agent is independently owned or operated;
• continued conversation and clarification are central;
• the agent must preserve its own identity.

Can an MCP server call an A2A agent?

Yes, at the implementation layer.

MCP host
  ↓ tools/call
MCP server
  ↓ A2A Message
Remote agent
  ↓ A2A Task/Artifact
MCP server
  ↓ MCP Task or tool result
Host

This pattern can make an A2A agent available to existing MCP hosts. The MCP server acts as an adapter. It must decide how to translate:

• MCP tool arguments into A2A Message Parts;
• A2A Task status into MCP Task status;
• Artifacts into content blocks or resources;
• auth_required into an MCP-compatible interaction;
• push events into polling or subscriptions;
• context and Task identifiers into explicit MCP handles;
• A2A errors into MCP results or JSON-RPC errors.

The adapter should expose these limitations rather than pretending to provide perfect semantic equivalence.

---

When to use MCP, A2A, or both

Use MCP when the caller retains orchestration

Use MCP without A2A when the system is primarily one orchestrator reaching capabilities.

Strong indicators include:

• one host retains planning and synthesis;
• the remote component performs a known operation;
• exact structured arguments are useful;
• local stdio deployment matters;
• the integration wraps an API, database, CLI or filesystem;
• cross-host reuse is desired;
• long-running work can be represented as one MCP Task;
• the remote service should not make independent delegation decisions.

Examples:

• search an enterprise knowledge base;
• read and edit files;
• create a repository issue;
• query a database;
• retrieve documentation;
• execute a deployment operation;
• convert time zones;
• fetch a webpage.

Use A2A when the remote agent owns the plan

Use A2A without MCP when independently implemented agents need to collaborate and their internal capabilities do not need to be standardized for the caller.

Strong indicators include:

• the remote party chooses its own plan;
• work spans multiple steps or systems;
• Tasks and Artifacts matter;
• continued dialogue is expected;
• agents cross team or organization boundaries;
• the remote agent’s internal tools should remain opaque;
• several bindings or asynchronous delivery modes matter;
• a durable agent identity and Agent Card are useful.

Examples:

• delegate a legal review to a legal agent;
• ask a supplier agent to prepare and negotiate a quote;
• coordinate specialist research agents;
• send an incident to an operations agent;
• collaborate with a travel-planning agent;
• ask a compliance agent to evaluate a process.

Use both when both boundaries are real

Use both when the architecture genuinely contains agents and capabilities.

The strongest combined indicators are:

• a coordinator delegates to specialists;
• each specialist needs reusable tools or data;
• independent vendors or frameworks operate the agents;
• local and remote capabilities must coexist;
• enterprise policy distinguishes delegation from execution;
• one protocol boundary cannot represent the entire responsibility graph cleanly.

A useful rule is:

If the remote party should answer “how,” use A2A.
If the caller already knows “how” and needs an operation, use MCP.

This is a heuristic, not a normative rule. Some MCP servers perform planning, and some A2A agents expose tightly bounded skills.

For ambiguous cases, use the 15-question decision framework in JSON or CSV, plus the 25-case boundary register. They are heuristics, not conformance rules.

---

How function calling and APIs fit

Function calling answers how a model proposes a structured action to its host. MCP answers how the host reaches a reusable capability. A2A answers how one application or agent collaborates with another independent agent. Those layers can appear in one request path; none replaces the underlying API or authorization policy. See MCP vs function calling and MCP vs API for the adjacent boundaries. [S339] [S054] [S001]

Pin versions at each protocol edge. The MCP protocol-version guide covers MCP negotiation and migration, while this page treats A2A as the stable 1.0 compatibility line.

---

Common myths and practical limitations

Misleading comparisons

“MCP is vertical and A2A is horizontal.”

The metaphor can orient a beginner, but it is not an architecture. MCP may cross organizational boundaries, and A2A agents may use local capabilities. The more precise distinction is capability access versus agent delegation.

“A2A replaces MCP.”

No. A2A’s own documentation describes the protocols as complementary. An A2A agent still needs tools and data, and MCP is one standardized way to provide them. [S337] [S340]

“MCP is for tools; A2A is for reasoning.”

Too absolute. An MCP server can use models and workflows internally, while an A2A agent can be deterministic. The protocol contract—not the presence of reasoning—is the important difference.

“An A2A skill is the same as an MCP tool.”

No. A tool has an invocation schema and method. A skill is advertised capability metadata; actual A2A work proceeds through Messages and Tasks. [S123] [S339]

“MCP Tasks and A2A Tasks are compatible.”

No. They have different status sets, operations, notification models and semantics. Both can represent long-running work, but an adapter must translate them. [S137] [S339]

“A signed Agent Card makes an agent safe.”

No. It can establish integrity and signer provenance. It does not verify competence, authorization, business behavior or downstream security. [S380] [S381]

“A2A requires agents to reveal their prompts and tools.”

No. Opacity is a design goal. The client needs the advertised interface and skills, not the remote implementation. [S337] [S341]

“MCP servers are never agents.”

Protocol role alone does not make a server an agent, but an MCP server implementation may invoke or contain agentic workflows.

“A2A agents cannot use MCP.”

They can, and the combined architecture is one of the protocols’ primary complementary patterns. [S340] [S356]

“Both protocols are formal internet standards.”

Not in the IETF, W3C or ISO sense as of the verification date. They are open protocol projects under public foundation governance.

“Because both are in AAIF, they will merge.”

There is no basis for that conclusion. Shared institutional hosting encourages coordination but does not eliminate separate governance or data models. [S355] [S070]

“A2A is always remote and MCP is always local.”

MCP supports both local and remote deployments. A2A is web-service oriented, but the protocol distinction is not simply local versus remote. [S057] [S339]

“A2A is just JSON-RPC for agents.”

A2A includes a normative data model, Agent Cards, Tasks, Artifacts, security metadata and several bindings. JSON-RPC is one binding, not the complete protocol. [S339]

“MCP is just function calling.”

Function calling is model-facing structured action selection. MCP is a client-server protocol for reusable capabilities. A host may map MCP tools into native function definitions.

“The protocol chooses the agent or tool automatically.”

No. Discovery provides metadata. Hosts, applications, models and policy systems decide what to expose and invoke.

Where MCP is a weak agent-collaboration contract

MCP can expose an agent as a tool and can represent long-running work through Tasks, but it does not currently provide the whole A2A model in core. Notable gaps for full agent collaboration include:

• a first-class Agent Card;
• a core skill model;
• core Task listing;
• Artifact semantics;
• a general push-notification model;
• multiple official remote protocol bindings;
• explicit agent provider identity and interfaces;
• cross-agent context grouping as a central object.

The MCP roadmap’s focus on agentic messaging primitives, events and identity shows that these issues are active areas of work. Roadmap priorities are not released behavior, and they should not be used to rewrite current protocol semantics. [S064]

Where A2A is a weak capability contract

A2A is not an ideal replacement for every capability boundary. Compared with MCP, it lacks the same first-class model for:

• local stdio server packages;
• simple runtime tool listing and invocation;
• URI-addressable resources as a server primitive;
• host-selected prompt templates;
• a small integration wrapper around one API;
• direct mapping of bounded operations into model function calling.

An Agent Card can advertise skills, but using a remote agent for every low-level database query or file operation can obscure schemas, permissions and performance.

---

Frequently asked questions

---

Sources, downloads, and update method

The comparison uses MCP 2026-07-28 and A2A 1.0. The Skills explanation was corrected on October 8, 2026 to reflect the released extension. Sources and comparison tables are linked below.

Sources (76)

S337 S338 S339 S340 S341 S342 S343 S344 S345 S346 S347 S348 S349 S350 S351 S352 S118 S353 S119 S354 S355 S356 S357 S358 S359 S360 S361 S362 S363 S364 S365 S366 S367 S368 S369 S370 S371 S054 S121 S055 S123 S124 S125 S127 S056 S057 S133 S317 S137 S059 S064 S058 S318 S050 S069 S070 S021 S372 S373 S374 S375 S376 S377 S378 S001 S379 S380 S381 S003 S382 S383 S384 S385 S386 S157 S387

See the source library and editorial policy for references and review dates.