MCP vs A2A Protocol: What's the Difference for AI Agents?

Quick Answer

MCP connects an AI application or agent to tools, data, prompts, and other capabilities. A2A connects independent AI agents to one another. Use MCP when an agent needs to call a database, search service, browser, API, or infrastructure tool. Use A2A when one agent needs to discover, delegate work to, exchange messages with, or receive results from another agent.

They are complementary rather than competing protocols:

In that architecture, A2A is the agent coordination plane, MCP is a capability and control plane, and the residential proxy endpoint is the website data plane. Neither protocol automatically routes a browser's website traffic through a proxy. The HTTP client or browser must be configured with the proxy endpoint explicitly.

The shortest useful distinction is:

• MCP: agent-to-tool. “What capability can I use, and how do I call it?”
• A2A: agent-to-agent. “Which independent agent can perform this job, and how do we manage the work?”
• Both: an A2A agent can use MCP internally while completing the task delegated to it.

Version note: This guide covers MCP specification 2026-07-28 and the stable A2A Protocol v1.0. A2A interfaces advertise protocol version 1.0, and HTTP clients send A2A-Version: 1.0. SDK package versions may advance independently of the protocol version.

Responsible-use note: Agents, tools, browsers, and proxies should be used only for lawful, authorized work. Follow applicable law, privacy requirements, website terms, access controls, and reasonable request rates. A protocol or proxy creates a technical path; it does not grant permission to access data or systems.

Key Takeaways

• MCP and A2A solve different relationships. MCP standardizes how an AI host uses external capabilities. A2A standardizes how independent agents communicate and delegate work.
• MCP exposes tools, resources, and prompts. A2A exposes an agent identity, skills, interfaces, security requirements, messages, tasks, and artifacts.
• Current MCP core is stateless. MCP 2026-07-28 uses self-contained requests with per-request metadata. Older explanations centered on an initialize handshake and connection-scoped sessions describe earlier protocol revisions.
• A2A tasks are stateful by design. A remote agent can return a task, move it through a lifecycle, request more input, stream updates, accept cancellation, and produce artifacts.
• MCP Tasks and A2A Tasks are not equivalent. MCP Tasks are an optional extension for long-running MCP operations. A2A Tasks are a core inter-agent work abstraction.
• Both protocols support discovery, but they discover different things. MCP discovers server capabilities and individual tools or resources. A2A uses an Agent Card to advertise an agent's skills, interfaces, modalities, and security requirements.
• A2A does not require JSON-RPC. MCP uses JSON-RPC 2.0 messages. A2A defines a canonical data model and operations with standard JSON-RPC, gRPC, and HTTP+JSON bindings.
• Protocol success is not proxy proof. A successful A2A message or MCP tool call does not prove that downstream website traffic used the intended residential route. Verify the browser or HTTP request separately.
• Use separate identities at every layer. An A2A taskId, MCP request ID, optional MCP Task ID, browser context, and proxy session all describe different state.
• Secure the whole chain. Authenticate peers, restrict tools, validate Agent Cards, contain untrusted web content, protect credentials, and enforce authorization on every operation.

MCP vs A2A: Side-by-Side Comparison

The table's most important row is the first relationship. If the remote system should expose a bounded operation, it is probably an MCP server. If it should remain an autonomous, independently deployed worker that accepts goals and manages its own execution, it is probably an A2A agent.

What Is MCP?

Model Context Protocol is an open protocol for connecting LLM applications to external context and capabilities. It separates three roles:

• The host is the AI application the user interacts with.
• A client inside the host communicates with one MCP server.
• The server exposes approved tools, resources, or prompts.

An MCP server might expose a documentation search tool, a CRM record lookup, a browser operation, a database resource, or a proxy-management action. The host decides which servers and capabilities are available to the model and whether a user must approve a call.

MCP's core primitives

The current MCP specification uses JSON-RPC 2.0 with stateless, self-contained requests and per-request capability metadata. A server must implement server/discover, although a modern client may call another supported RPC directly and handle version errors. Individual primitives have their own discovery operations, such as tools/list.

This matters because many MCP tutorials still describe the 2025 protocol lifecycle. Earlier revisions used initialize, initialized, connection-scoped capabilities, and an HTTP session identifier. MCP 2026-07-28 replaced that normal core flow with per-request metadata. Legacy interoperability remains specified, but new architecture should not rely on hidden connection state.

When an MCP tool needs state across calls, it should return an explicit opaque handle. A browser server, for example, could return a browser_context_id, then require that identifier on later navigation calls. That handle is application state stored behind the MCP server—not an MCP protocol session and not a proxy session.

MCP transports

The MCP transport specification defines two standard options:

• stdio: newline-delimited protocol messages over a client-launched subprocess's standard input and output. This is common for local tools.
• Streamable HTTP: each message is an HTTP POST to a single endpoint. A response can be one JSON object or a request-scoped Server-Sent Events stream.

Custom transports are allowed if they preserve MCP semantics and the per-request metadata model. Transport choice changes deployment and security concerns, but it does not change whether a remote capability is a tool, resource, or prompt.

What Is A2A?

Agent2Agent Protocol is an open standard for communication between independent AI agent systems. The agents may use different models, languages, frameworks, or internal tools. They do not need to reveal their private memory, orchestration graph, prompts, or implementation details to collaborate.

A2A lets a client agent:

1. Discover a remote agent through its Agent Card.
2. Inspect the agent's skills, supported interfaces, content types, and security requirements.
3. Send a message containing text, files, or structured data.
4. Receive a direct message for a simple interaction or a Task for stateful work.
5. Follow progress through polling, streaming, task subscriptions, or push notifications.
6. Provide more input if the task pauses for clarification or authentication.
7. Receive final results as Artifacts.

A2A v1.0, announced in March 2026 as the protocol's first stable production-ready line, defines three layers: a canonical data model, abstract operations, and protocol bindings. Standard bindings cover JSON-RPC, gRPC, and HTTP+JSON/REST. This is why “both use JSON-RPC” is an incomplete comparison: MCP always uses JSON-RPC messages, while JSON-RPC is one of several A2A bindings.

A2A's core objects

The Message-versus-Artifact distinction is useful. Messages carry communication: requests, clarification, status context, and conversational turns. Artifacts carry reliable task outputs. A production client should not scrape an agent's conversational prose when the remote service can return a typed Artifact instead.

What Are the Main Differences Between MCP and A2A?

The protocols differ in what is on the other side, how work is represented, how capabilities are discovered, and where autonomy lives.

1. MCP exposes capabilities; A2A exposes agents

An MCP tool is an operation with a name, description, input schema, and optional output schema. The caller chooses the tool and supplies its arguments. The server executes that bounded capability.

An A2A agent advertises broader skills and accepts a message or goal. It may plan several steps, select its own tools, call models, ask for clarification, or delegate again before returning an outcome. The client does not need to know how the remote agent works internally.

Suppose a coordinator needs a localized price:

• With MCP, it might call fetch_product_page with a URL and market, then interpret the returned page evidence itself.
• With A2A, it might ask a price-research agent to compare a product in one market. That agent decides which approved sources and tools to use, then returns a structured comparison Artifact.

The A2A skill describes an outcome the agent is likely to perform well. It is not a directly invocable function signature. The MCP tool is a callable capability with a concrete schema.

2. MCP and A2A discover different layers

MCP discovery answers: What can this server provide? A client can inspect server capabilities and list tools, resources, or prompts. Discovery remains scoped to the server the client is already configured to reach.

A2A discovery answers: What agent is this, how can I reach it, and what work can it do? A public Agent Card is normally served from /.well-known/agent-card.json. It can list several interfaces, the preferred protocol binding, supported A2A version, media types, skills, optional streaming or push support, and authentication schemes.

An Agent Card is descriptive input, not proof of trust. Production clients should retrieve cards over HTTPS, pin or validate expected providers where appropriate, verify signatures when used, and apply a local policy before enabling a newly discovered agent. An authenticated extended Agent Card can disclose additional capabilities without putting internal details on the public endpoint.

3. MCP core is request-oriented; A2A is work-oriented

MCP's normal shape is a self-contained request and response: list tools, call a tool, read a resource, or obtain a prompt. A tool can return explicit handles when its own backend is stateful.

A2A can also return a simple direct Message, but its distinctive abstraction is the Task. The remote agent creates the Task ID, owns its state transitions, and can expose task history and Artifacts. Typical states include:

• TASK_STATE_SUBMITTED
• TASK_STATE_WORKING
• TASK_STATE_INPUT_REQUIRED
• TASK_STATE_AUTH_REQUIRED
• TASK_STATE_COMPLETED
• TASK_STATE_FAILED
• TASK_STATE_CANCELED
• TASK_STATE_REJECTED

This lifecycle fits work that may outlive one HTTP request, require a human decision, or continue after either party reconnects.

4. MCP returns capability results; A2A returns agent communication and artifacts

An MCP tool result can contain text, structured JSON, images, audio, resource links, or embedded resources. An output schema can make the result machine-verifiable.

An A2A response can be a direct Message or a Task. During task execution, the remote agent can emit status and Artifact updates. Final deliverables should be placed in Artifacts, keeping conversation separate from output.

Both protocols can carry structured data. The distinction is semantic: an MCP result comes from a capability invocation; an A2A Artifact comes from delegated agent work.

5. MCP defines transports; A2A defines bindings

MCP's JSON-RPC semantics are constant across stdio, Streamable HTTP, or a conforming custom transport.

A2A starts with one canonical data model and set of operations, then maps them into bindings. A deployment can offer HTTP+JSON, JSON-RPC, gRPC, or multiple interfaces at once. The Agent Card tells clients which interface and version to use.

This affects gateways and observability. An MCP gateway can reason about JSON-RPC method names such as tools/call. An A2A gateway may need to normalize REST paths, JSON-RPC methods, or gRPC methods into the same task-level telemetry.

6. They create different trust boundaries

An MCP server is trusted with the data and actions exposed through its capabilities. A compromised or malicious server can misdescribe tools, return hostile content, or misuse broad permissions.

An A2A remote agent is a separate principal with more autonomy. It may retain task state, call its own tools, contact other systems, and return content assembled from several sources. The client must authenticate that agent, scope what it may receive, and validate what it returns.

Using both protocols creates nested delegation:

Each arrow needs an explicit policy. Permission to ask an agent for research is not automatically permission for every tool that agent could call.

Are MCP and A2A Competing Protocols?

No. The A2A specification explicitly describes A2A and MCP as complementary.

MCP standardizes access to tools, APIs, data sources, and resources. A2A standardizes collaboration between independent agents. One agent can expose an A2A interface to peers while consuming several MCP servers internally.

A useful software analogy is:

• MCP resembles a standardized plugin or capability interface for an AI host.
• A2A resembles a service-to-service collaboration contract designed around agent work.

The analogy is not exact, but it prevents the most common architecture error: wrapping every deterministic function in a remote agent, or flattening every autonomous service into one giant tool list.

Who created and governs MCP and A2A?

Anthropic introduced MCP in November 2024. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, while the MCP maintainers retained responsibility for day-to-day technical direction.

A2A was created by Google and launched in April 2025. The Linux Foundation became the protocol project's home in June 2025. On August 27, 2026, A2A was accepted as a Growth Stage project in the Agentic AI Foundation, placing it alongside MCP in the Linux Foundation-directed open agentic ecosystem. They remain separate protocols, specifications, projects, and technical communities.

MCP Tasks vs A2A Tasks

Both ecosystems now use the word “Task,” but the abstractions remain different.

MCP Tasks let a server return a durable task handle for an operation that may take minutes, survive disconnects, require mid-flight input, or wrap an external job system. The client can poll tasks/get, respond through tasks/update, or request cancellation. Client support varies because the feature is an extension.

That does not turn the MCP server into an A2A peer. A long-running CI tool remains a tool even if it has a task ID. Conversely, an A2A agent can use MCP Tasks internally—for example, to wait for a batch extraction tool—while maintaining its own A2A Task for the coordinator. Those two task IDs must not be treated as interchangeable.

What Do MCP and A2A Look Like on the Wire?

These minimal examples show the difference in intent. They are protocol illustrations, not drop-in production clients. Use the current official schema and an official or well-maintained SDK for validation, authentication, error mapping, retries, and streaming.

MCP tool-call example

This current-era MCP request calls an illustrative read-only infrastructure tool. In MCP 2026-07-28, every request declares its protocol version and client capabilities in params._meta; clients should also include clientInfo, but it is not a strict requirement in the final specification.

For Streamable HTTP, important body fields are mirrored into required request headers. A tools/call request therefore includes MCP-Protocol-Version, Mcp-Method, and Mcp-Name; the header values must agree with the JSON body:

The corresponding JSON-RPC body is:

The tool name is illustrative. A client should discover the server's actual allowlisted tools rather than assuming names or exposing every advertised operation to a model.

A2A delegated-task example

This A2A HTTP+JSON request asks an independent research agent for an outcome rather than choosing its internal tool:

The remote agent may return a direct Message for a simple answer or a Task that continues asynchronously. The client does not specify whether the agent should use HTTPX, Playwright, MCP, a database, or another internal agent.

A2A Agent Card example

An abbreviated public Agent Card might advertise the research outcome and the interface used above:

Do not put proxy credentials, model keys, private hostnames, internal tool inventories, or sensitive operating instructions in a public Agent Card.

How MCP and A2A Work Together

The strongest architecture uses each protocol at the boundary it was designed for.

Consider a coordinator that creates a localized market report:

1. The coordinator retrieves an approved research agent's Agent Card and checks its identity, HTTP+JSON interface, A2A 1.0 support, accepted media types, security requirements, and research skill.
2. The coordinator sends an A2A message with the requested market, approved target scope, evidence requirements, deadline, and output schema.
3. The remote agent returns an A2A Task and begins planning the work.
4. Inside that task, the research agent uses narrow MCP tools for approved capabilities—for example, reading an access-point configuration or looking up an internal catalog.
5. If it needs a live webpage, its HTTP client or browser opens the approved destination through a Proxidize Residential Proxy endpoint.
6. The agent validates the final URL, response type, visible country/currency/store signals, source timestamp, and extracted fields.
7. It publishes progress through A2A status updates and returns the final cited dataset as an Artifact.
8. The coordinator validates the Artifact schema, citations, and policy before using it in a report.

The remote research agent remains opaque at the A2A boundary. It does not expose its prompt, graph, browser implementation, MCP credentials, or proxy password. The coordinator receives only the contract it needs: advertised skills, secure interface, task state, and evidence.

Combined architecture with Proxidize

Four network paths exist here, and they should not be collapsed into one:

A residential proxy is usually inappropriate for A2A service-to-service messages. Those messages should use stable, authenticated application networking. If an organization requires an enterprise forward proxy for outbound services, that is a separate infrastructure policy—not the residential exit used to observe a target website from a particular market.

Where Proxidize Fits

Proxidize can appear in two different parts of an MCP-and-A2A system.

First, the Proxidize MCP server can expose approved proxy-management capabilities to an MCP-compatible client. Depending on the account and enabled tools, that can include inspecting subscription or usage information, checking outbound IPs, changing locations, rotating supported products, or managing access points. Keep high-impact operations behind explicit approval and expose only the tools required by the workflow.

Second, a Proxidize Residential Proxy carries the actual HTTP or browser traffic to target websites. This is the data plane that provides residential routing, country/city/ISP targeting, and rotating or Sticky session behavior.

This separation makes the system easier to audit. An MCP log can show that an access point was inspected. An A2A log can show that the research task completed. Only the HTTP/browser evidence can show which route reached the target and what the target actually returned.

Map one A2A task to one proxy work unit

For a coherent multi-page workflow, map the A2A Task to an application work unit with one isolated browser context and one Sticky proxy session:

Use a Sticky session when pages belong to one continuous workflow: search, open result, compare variants, add evidence, and verify. Rotate at a clean boundary before an unrelated task. Use Random or rotating behavior for independent one-shot observations where continuity is not required.

Sticky does not mean permanent. Residential exits can change because of provider limits, upstream availability, or connection loss. Your application must detect continuity changes and decide whether to restart the affected work unit, revalidate state, or continue with an explicit evidence note.

Session state is not one thing

Use one application-owned work_unit_id to correlate safe logs across layers, but keep the native IDs distinct. Do not use a correlation ID as a bearer secret, and do not expose credential-bearing proxy URLs in A2A metadata, MCP arguments, model prompts, Artifacts, or logs.

When Should You Use MCP, A2A, Both, or Neither?

Ask three questions:

1. Is the remote party a bounded capability or an autonomous worker? Choose MCP for the former and A2A for the latter.
2. Who owns the execution plan? If the caller selects the exact operation, MCP fits. If the remote system decides how to achieve a delegated outcome, A2A fits.
3. Does the work need a durable inter-agent lifecycle? A2A is designed for that. Use MCP Tasks only when the long-running object is still an MCP operation.

Do not adopt both simply because both are popular. A small agent with two local functions may need neither. Protocols earn their place when they create a reusable boundary between independently evolving components.

How Do MCP and A2A Fit Existing Agent Frameworks?

Frameworks and protocols sit at different layers. A framework supplies the agent loop, orchestration, state, and developer APIs. MCP and A2A standardize selected boundaries around that runtime.

An agent built with any framework can conceptually sit behind an A2A server if an adapter implements the current protocol and preserves authorization, task, and Artifact semantics. Do not assume every framework release has native A2A support, however. Framework APIs and protocol adapters change faster than the architectural distinction.

For implementation-level proxy patterns, see the Proxidize guides for the OpenAI Agents SDK, LangGraph, Claude Browser Use, Google ADK, Microsoft Agent Framework, and CrewAI. In every case, the framework owns orchestration while its HTTP or browser tool owns proxy configuration.

Security: Treat Every Boundary as Untrusted

MCP and A2A reduce integration inconsistency, but neither makes agent actions safe by default. Security must cover identity, authorization, data flow, tool execution, delegated work, web content, and output validation.

Authenticate the endpoint, then authorize the operation

For remote MCP, follow the current MCP authorization specification and use audience-bound access tokens. For local stdio, pass credentials through the process environment rather than prompts or command-line arguments that may be logged.

For A2A, accept only approved Agent Cards and interfaces. Authenticate every request with a scheme the card advertises, then enforce authorization on each task operation. Knowing a taskId must never be enough to read, cancel, or subscribe to that task.

Apply least privilege after discovery

Discovery is not authorization. An MCP server may advertise twenty tools while one agent needs two read-only operations. An A2A Agent Card may advertise five skills while the caller is entitled to one.

Build a local allowlist after discovery. Separate read and mutation scopes. Require user approval for consequential actions. Set tool-call, task, time, bandwidth, and cost budgets in deterministic code.

Do not trust descriptions or content

MCP tool descriptions and annotations can be misleading if the server is not trusted. A2A Agent Cards and remote-agent outputs can also be malicious or compromised. Webpages introduce a third untrusted instruction source through prompt injection.

Treat all three as data. Do not let a page, tool result, or remote agent override the system's destination policy, reveal credentials, expand permissions, or silently add a new server. Preserve source provenance and tell the model which content is quoted evidence rather than instruction.

Contain browsers and HTTP tools

For network-facing research agents:

• Allowlist destination schemes and hostnames.
• Resolve and reject private, loopback, link-local, and metadata-service addresses.
• Revalidate every redirect rather than enabling blind redirect following.
• Limit response bytes, content types, download sizes, page count, and execution time.
• Isolate browser contexts, cookies, credentials, and proxy sessions by work unit.
• Keep model, A2A, MCP, and proxy credentials outside model-visible arguments.
• Disable or restrict arbitrary file upload, shell execution, extension installation, and cross-origin credential access.
• Validate extracted values and citations before accepting an Artifact.

These controls reduce SSRF, data exfiltration, confused-deputy behavior, and cross-task contamination.

Secure A2A push notifications

Push notifications are outbound requests from the remote agent to a callback URL supplied by the client. Validate callback URLs against SSRF, require HTTPS, use a unique single-purpose authentication token, verify the expected task ID, rate-limit the endpoint, and process duplicate notifications idempotently. The A2A security section makes authorization scoping and webhook security explicit requirements.

Reliability, Retries, and Observability

Retry at the layer that failed. A timeout from an A2A agent is different from an MCP tool error, which is different from a browser navigation failure or target HTTP 429.

Never retry a whole A2A task just because one downstream page fetch failed. The remote agent may have already created state or performed an action. Give each mutating operation an idempotency design, record task identifiers durably, and distinguish “request outcome unknown” from “request failed before execution.”

For observability, record safe structured events rather than raw prompts and secrets:

Redact query strings, authorization headers, cookies, proxy usernames/passwords, signed URLs, raw page bodies, and sensitive model input. Hash or alias identifiers when full values are not necessary for diagnosis.

Common MCP vs A2A Mistakes

Treating A2A as a replacement for MCP

A2A does not provide an equivalent to an MCP server's tool, resource, and prompt catalog. It provides an inter-agent work contract. Use both when a remote agent needs standardized tools.

Turning every tool into an agent

A database lookup with a fixed schema does not become better because it has an Agent Card and Task lifecycle. Keep deterministic, narrow capabilities tool-shaped.

Turning every remote agent into one broad tool

Wrapping an autonomous service as do_anything hides task state, skills, supported modalities, Artifact semantics, and peer authentication. Use A2A when those agent-level features matter.

Assuming all MCP documentation describes the current protocol

MCP 2026-07-28 is stateless at the core. Code built only around the older initialize handshake or Mcp-Session-Id belongs to the legacy compatibility path, not the modern default.

Confusing MCP Tasks with A2A Tasks

The names overlap, but the IDs, lifecycles, security scopes, and ownership are different. Store them in separate fields.

Sending A2A traffic through the residential endpoint

Residential proxies belong on the HTTP client or browser that visits target websites. A2A messages normally use stable, authenticated service networking.

Calling a configured market “verified”

A country selector is configuration. Verify the observed exit separately, then validate what the target itself shows: currency, language, store, availability, or another market-specific field.

Letting delegated agents expand their own permissions

A remote agent should not be able to add MCP servers, enable mutation tools, change proxy scope, or approve its own consequential action merely because untrusted content suggested it.

Logging complete protocol payloads

A2A messages, Artifacts, MCP arguments, and tool outputs may contain private data or credentials. Log allowlisted metadata and evidence references, not everything by default.

Troubleshooting MCP and A2A Systems

Conclusion

MCP and A2A are two pieces of the same emerging agent infrastructure stack. MCP gives AI applications a standard way to discover and use capabilities. A2A gives independent agents a standard way to discover one another, delegate stateful work, exchange messages, and return artifacts.

Use MCP for tools and context. Use A2A for agents and delegated outcomes. Use both when a remote agent needs standardized capabilities to finish its work.

For web research, keep the network layer separate: the agent framework orchestrates, A2A coordinates, MCP exposes approved capabilities, the browser executes, and Proxidize routes the target-website request. Explore Proxidize proxies for AI agents or create a Residential Proxy access point when your authorized workflow needs real residential routes, geo-targeting, and rotating or Sticky sessions.