Multi-Agent Protocols Explained: MCP, A2A, and ACP Standards

Multi-agent protocols explained is a useful framing for engineering teams deciding how an AI system should access tools, share context, delegate work, and exchange results. The current official specifications describe different jobs. MCP standardizes the connection between an LLM application and external data or tools. [1] A2A standardizes communication and collaboration between opaque agentic applications. [2] The ACP documentation describes an open REST-based protocol for agent interoperability and now carries an important update that ACP is part of A2A under the Linux Foundation. [3]

This distinction matters because a protocol is not an agent framework, a model, a workflow engine, or a security certification. It defines messages, capabilities, discovery, transport, and boundaries. An implementation still needs identity, authorization, consent, logging, validation, rate limits, error handling, and an owner for consequential actions.

This rewrite removes unsupported claims about protocol wars, fixed adoption counts, universal enterprise readiness, and an automatic migration path. It uses the official MCP specification, the A2A protocol site and repository, and the ACP documentation. Readers can compare this standards discussion with our coding-agent workflow guide, multimodal systems analysis, and AI finance workflow comparison.

What You'll Learn

• How MCP, A2A, and ACP divide tool access, agent collaboration, and message transport
• What official specifications say about discovery, tasks, resources, prompts, tools, and artifacts
• Why protocol compatibility does not remove identity, consent, authorization, and review work
• How to choose a layered protocol architecture and test it before production deployment

What These Protocols Solve

AI applications often need two kinds of connectivity. An agent may need to read a database, call a search service, inspect a repository, or invoke a function. That is an agent-to-tool problem. The same system may need a research agent to ask a planning agent for help, receive a result, and continue a task without exposing private internal memory. That is an agent-to-agent problem.

MCP describes hosts, clients, and servers. The host is the LLM application, the client is a connector inside the host, and the server provides context and capabilities. [1] A2A describes independent agentic applications that can discover capabilities, negotiate interaction modalities, collaborate on long-running tasks, and keep internal state or tools opaque. [2]

ACP's documentation describes a REST-based communication layer for agent interoperability, with synchronous and asynchronous communication, streaming, discovery, and long-running tasks. [3] The same page now states that ACP is part of A2A under the Linux Foundation. [3] That status should be checked again before a new implementation because project governance and migration guidance can change.

MCP: Agent-to-Tool Communication

The MCP specification says MCP enables LLM applications to integrate with external data sources and tools. [1] It standardizes how an application shares context with a model and exposes capabilities through a common protocol. The model may use a resource for information, a prompt for a templated workflow, or a tool for an executable function.

MCP uses JSON-RPC 2.0 messages between hosts, clients, and servers. [1] The specification describes stateless self-contained requests and per-request capability negotiation as base-protocol details. [1] An implementation should still document session behavior, timeouts, retries, idempotency, and what happens when a server becomes unavailable.

The server features in the specification include resources, prompts, and tools. [1] Resources provide context and data for the user or model. Prompts provide templated messages and workflows. Tools are functions for the model to execute. [1] These names do not define a safe business process by themselves. A tool that writes to a ticket system needs narrower authorization than a tool that reads a public document.

MCP also describes client-side elicitation and utilities such as progress tracking, cancellation, configuration, and error reporting. [1] Optional extensions include asynchronous tasks, skills over MCP, and interactive MCP Apps. [1] Extensions require explicit support from both client and server and are negotiated during initialization. [1]

A2A: Agent-to-Agent Collaboration

The A2A project describes an open standard for communication and collaboration between AI agents built with different frameworks and vendors. [2] It is designed for agents to discover capabilities, negotiate interaction modalities, collaborate on long-running tasks, and operate without exposing internal state, memory, or tools. [2]

A2A explicitly distinguishes itself from MCP. The A2A site says MCP is for agent-to-tool communication, while A2A is for agent-to-agent communication. [2] It also says A2A is not an agent development kit, not a tool-call protocol, not a replacement for MCP, and not an interactive messaging application. [2] That negative definition is as important as the feature list because it prevents teams from using a collaboration protocol as a substitute for tool authorization.

The A2A repository documents JSON-RPC 2.0 over HTTP(S), Agent Cards for discovery, synchronous request and response, streaming through SSE, asynchronous push notifications, and rich data exchange for text, files, and structured JSON. [2] These features allow a client agent to ask a remote agent for work without requiring access to the remote agent's internal implementation.

Opacity is a design boundary, not proof of safety. A remote agent can still return a wrong answer, misinterpret a task, leak information through an artifact, or exceed a business policy. Treat the Agent Card, endpoint, authentication scheme, task scope, and returned artifact as inputs that require validation.

ACP and Its Current Relationship to A2A

The ACP documentation describes the Agent Communication Protocol as an open protocol for connecting agents, applications, and humans through a standardized RESTful API. [3] It lists synchronous and asynchronous communication, streaming, stateful and stateless patterns, online and offline discovery, and long-running tasks. [3]

ACP's documented transport vocabulary is different from MCP's JSON-RPC framing and A2A's documented JSON-RPC over HTTP(S) features. ACP describes REST endpoints and MIME types for content identification, with text, images, audio, video, and custom binary data represented through message types. [3] A protocol comparison should therefore distinguish the historical or current implementation semantics from the project status.

The ACP welcome page carries an important status banner: “ACP is now part of A2A under the Linux Foundation” and links to a migration guide. [3] This does not mean every ACP deployment will migrate automatically or that every endpoint is already A2A-compatible. Inventory the current ACP version, endpoint behavior, message formats, discovery method, authentication, and operational owner before changing a live integration.

For a new build, read the current A2A specification and the ACP migration material together. For an existing ACP deployment, first freeze a compatibility test suite. Preserve content types, synchronous and asynchronous behavior, discovery, task status, error responses, and authentication expectations while evaluating the target implementation.

How the Protocols Fit as a Stack

A layered architecture can use MCP inside an agent and A2A between agents. The A2A site gives the same conceptual relationship: MCP equips an individual agent with tools, APIs, and resources, while A2A allows independent agents to discover one another, delegate tasks, and share results. [2]

Consider a research workflow. A client agent uses MCP to query an approved database and retrieve a document. It then sends a bounded task to a specialist agent over A2A. The specialist returns a structured artifact. The client validates the artifact, asks another tool for corroboration, and presents the result to the user for review. The protocol layers do not decide whether the final answer is accurate.

A stack should make authority visible at each hop. The host authorizes the MCP client. The MCP server authorizes tools and resources. The A2A client authenticates the remote agent. The remote agent decides whether to accept the task. The application validates the returned artifact before it triggers another action.

ACP can appear in a compatibility or migration layer where an existing agent service still exposes ACP semantics. Do not use a diagram that collapses MCP, A2A, and ACP into one generic “agent protocol.” Their scopes, transport descriptions, and current project relationships must remain explicit.

Teams evaluating AI systems can also read our AI rights and provenance guide. Protocol interoperability increases the number of places where provenance needs to be preserved.

Discovery and Capability Negotiation

Discovery is how an application learns what a remote service can do and how to contact it. A2A documents Agent Cards that describe capabilities and connection information. [2] The client should retrieve an Agent Card through a trusted route, validate its origin, verify its authorization requirements, and compare the advertised skills with the task it wants to submit.

MCP uses initialization and capability negotiation between client and server. The specification also describes resources, prompts, tools, and optional extensions that require support from both sides. [1] Capability negotiation is not a license to call every discovered tool. It tells the implementation what is available. The host still needs a policy for which capabilities the user or workflow may authorize.

Do not trust a capability description merely because it uses a familiar name. The MCP specification warns that tool descriptions and annotations should be treated as untrusted unless obtained from a trusted server. [1] That is an important prompt-injection boundary. A description can explain a function, but it cannot override the application's security policy.

Version negotiation should be tested separately from feature negotiation. A client may understand a protocol version but not a new extension. A remote agent may advertise a skill but lack the data or permissions needed at runtime. Store the negotiated capabilities in logs so a failure can be explained after the fact.

Tasks, Messages, and Artifacts

Long-running work needs a lifecycle, not just a request and a final string. MCP's optional Tasks extension describes asynchronous execution, polling, mid-flight input, and durable handles. [1] A2A describes synchronous requests, streaming, asynchronous push notifications, long-running tasks, and rich data exchange. [2] ACP describes long-running tasks and asynchronous communication. [3]

Define states before implementation. A task can be accepted, running, waiting for input, completed, failed, cancelled, or expired. The exact state names depend on the protocol and implementation. The application should still define what each state means for user experience, retries, billing, resource locks, and downstream actions.

Messages need sender and recipient identity, correlation information, content type, size limits, and validation rules. Artifacts need provenance, schema validation, scanning, and retention. A large artifact or a result that contains executable instructions should not be passed to another tool without review.

Streaming also needs a completion rule. A partial response can be displayed to a user without being treated as a final result. Push notifications need replay protection, authentication, deduplication, and cancellation. These controls belong to the application even when the protocol provides a transport or message shape.

Transport Choices for Real-Time and Async Work

MCP's base specification is organized around JSON-RPC messages and includes utilities for progress, cancellation, and error reporting. [1] A2A documents JSON-RPC 2.0 over HTTP(S), SSE streaming, and asynchronous push notifications. [2] ACP describes REST communication, streaming, and asynchronous operation while also supporting synchronous interaction. [3]

Transport selection should follow the workload. A short tool call may fit a synchronous request. A long analysis may need polling or push updates. A live user interface may need streaming. An offline or scale-to-zero deployment may need a discovery record that is available even when the agent is not running, as ACP documentation describes. [3]

Do not confuse transport with delivery guarantees. HTTP or SSE does not automatically provide exactly-once execution, durable state, secure replay, or correct cancellation. Add an idempotency key, timeout, retry policy, dead-letter path, and audit record for operations with side effects.

Security, Identity, and Governance

MCP's security section says users must understand and consent to data access and operations, hosts must obtain consent before exposing user data to servers, and tools can represent arbitrary code execution. [1] The specification also says MCP cannot enforce those principles at the protocol level. [1] The host and server implement the consent and authorization flows.

A2A describes secure and opaque collaboration, authentication, security, and observability as design goals. [2] ACP describes interoperability across agents and organizations. [3] Neither description eliminates the need to verify the remote identity, authorization audience, credential scope, data residency, logs, and incident response process.

Use least privilege at every layer. An MCP server should expose only the resources and tools required for the task. An A2A agent should receive a narrow task and only the context it needs. A legacy ACP endpoint should be isolated during migration and monitored for unexpected traffic. Do not pass production credentials through a generic agent context.

Governance must cover protocol versions, server registration, Agent Card approval, tool ownership, skill changes, schema changes, and deprecation. Keep a compatibility matrix and a rollback plan. The Linux Foundation relationship described by A2A and ACP makes governance visible, but each organization remains responsible for its own deployment decisions.

For a related view of identity and automation risk, see our coding-agent controls guide and AI data-permission comparison. A protocol does not turn an unreviewed integration into a trusted one.

Protocol Comparison by Responsibility

The most useful comparison is not which acronym is newest. It is which responsibility the protocol standardizes and which responsibility remains in the host application, agent framework, or organization.

This table summarizes the fetched primary sources, not a claim that implementations are automatically interoperable. A product may support one protocol partially, add proprietary extensions, or expose a different authentication and billing model. Test the actual endpoint and version.

Migration and Compatibility Planning

Migration starts with inventory. List every MCP server, A2A endpoint, ACP service, Agent Card, tool, resource, prompt, task type, message schema, artifact format, credential, and downstream consumer. Record the owner and the data classification for each connection.

Next, build contract tests. Test discovery, authentication failure, unsupported capability, invalid input, timeout, cancellation, partial stream, duplicate notification, malformed artifact, and remote-agent refusal. A migration is incomplete if only the happy path works.

For ACP, the official documentation's status banner and migration link are the starting point. [3] Do not translate REST fields to A2A fields by name alone. Compare task lifecycle, MIME types, discovery, asynchronous updates, error semantics, and authentication. Preserve a dual-run or replay path where the risk justifies it.

For MCP, check extension support during initialization because the specification says extensions are opt-in and require explicit support from both client and server. [1] For A2A, validate Agent Card changes and supported modalities. [2] Keep old and new contract versions visible until the test suite passes and the owner approves retirement.

A Production Rollout Checklist

Start with a read-only MCP server or a nonconsequential A2A task. Confirm consent screens, identity, logs, timeouts, cancellation, error handling, and artifact validation. Do not begin by connecting an agent to a write-capable production tool or by allowing a remote agent to trigger deployment.

Use a small set of representative tasks and replay them against the same protocol versions. Measure successful completion, invalid-message handling, retry behavior, human interventions, and time to diagnose a failure. Keep the data and prompts synthetic where possible. If real data is required, minimize fields and set retention limits.

Require a human review for tool calls that change records, send communications, spend money, alter permissions, deploy code, or expose sensitive data. The MCP specification's consent principles support this control. [1] A2A and ACP collaboration features do not remove it.

Finally, document the protocol boundary in the architecture record. State which system owns identity, which component validates capabilities, where consent is collected, where logs are stored, how cancellation works, and who can disable an endpoint. A protocol diagram is useful only when the ownership lines are operationally real.

Our related AI rights and provenance guide and AI finance workflow guide apply the same evidence rule: describe what the source says, then define the control needed before action.

In 2026, MCP, A2A, and ACP should be read as related protocol stories with different responsibilities and a changing governance context. MCP provides the agent-to-tool and context boundary. A2A provides a standard for communication between independent agents. ACP documentation describes REST-based agent interoperability and now states that ACP is part of A2A under the Linux Foundation. [1] [2] [3]

The practical choice is therefore architectural. Use MCP where an agent needs tools or data. Use A2A where independent agents need to discover, delegate, and exchange results. Treat ACP integrations according to the current migration guidance. Then add consent, identity, authorization, validation, observability, cancellation, and rollback around the protocol layer.