A Survey of Agent Interoperability Protocols (MCP, ACP, A2A, ANP) — L2 #

§1 TL;DR #

Qualitative survey comparing four emerging agent communication protocols—MCP (tool invocation), ACP (structured messaging), A2A (enterprise task delegation), ANP (decentralized P2P)—across 11 dimensions, concluding no single protocol suffices and proposing a phased adoption roadmap from MCP → ACP → A2A → ANP.

§2 痛点 / 方法 / 结果 #

Q1 痛点 #

LLM-powered autonomous agents lack standardized protocols for tool integration, context sharing, and cross-platform coordination. Ad-hoc integrations fragment the ecosystem:

• Context standardization gap: no unified mechanism to deliver structured context (tools, datasets, sampling instructions) to LLMs
• Communication barriers: heterogeneous agent stacks create isolated behavior with no shared messaging format
• Collaboration vacuum: no framework for dynamic capability negotiation, shared task management, or peer discovery
• Internet-hostile architecture: the web is optimized for human interaction, not for low-latency agent-to-agent communication with decentralized identity

Paper's Figure 1, verbatim (caption: "Protocol-aligned solution to challenges in agent communication"). Each of the four challenges maps directly to one protocol's design space: MCP solves context standardization, ACP solves messaging barriers, A2A solves collaboration absence, ANP solves internet-agnostic communication.

Q2 方法 #

The survey maps each challenge to a purpose-built protocol and analyzes their architectures in depth:

The analysis covers: architecture model, discovery mechanism, identity/auth, message format, core components, transport layer, session support, target scope, primary use case, strengths, and limitations.

核心技术壁垒: The paper's central insight is that agent interoperability is a layered problem requiring distinct protocols at different trust/scope boundaries. No single protocol can simultaneously optimize for tight LLM–tool coupling (MCP), structured multimodal messaging (ACP), enterprise coordination (A2A), and trustless open-internet discovery (ANP). The composability of these layers—not any individual protocol—is the hard unsolved problem.

Q3 结果 #

• Qualitative-only evaluation via an 11-dimension comparison table (Table 7); zero empirical benchmarks or performance measurements
• Key finding: protocols are complementary, not competitive
• Phased adoption roadmap: Stage 1 (MCP for tool invocation) → Stage 2 (ACP for agent messaging) → Stage 3 (A2A for enterprise collaboration) → Stage 4 (ANP for open agent markets)
• Security analysis per lifecycle phase (Creation/Operation/Update/Termination) for all four protocols

§3 架构 / 方法图 #

Protocol Architecture Overview #

Paper's Figure 3, verbatim (caption: "An overview of MCP [7]"). MCP follows a client–server model where the Host application connects to MCP Servers exposing four primitives: Tools (model-controlled), Resources (application-controlled), Prompts (user-controlled), and Sampling (server-controlled). Communication uses JSON-RPC 2.0 over HTTP or Stdio with optional SSE.

Paper's Figure 4, verbatim (caption: "An overview of A2A"). A2A introduces a three-actor model (User → Client Agent → Remote Agent) where Remote Agents publish Agent Cards (JSON at /.well-known/agent.json) declaring skills, auth requirements, and I/O formats. Communication uses JSON-RPC 2.0 with SSE streaming and optional push notifications.

Paper's Figure 5, verbatim (caption: "An overview of ACP"). ACP uses a brokered architecture: ACP Client → ACP Server (middleware) → ACP Agent(s). The server handles routing, session persistence, and lifecycle management. Discovery via registry APIs or offline manifest files at /.well-known/agent.yml.

Paper's Figure 6, verbatim (caption: "An overview of ANP [12, 11]"). ANP is fully decentralized: agents identify via W3C DIDs (did:wba), publish JSON-LD agent descriptions, and discover peers through /.well-known/agent-descriptions directories. A Meta-Protocol Negotiator enables runtime protocol alignment between unknown agents.

Layered Interoperability Model (Mermaid) #

Protocol Lifecycle (Common Four-Phase Pattern) #

All four protocols share a common lifecycle structure:

§4 作者证明 #

无形式化作者证明 — 仅实证

This is a qualitative survey with zero numbered equations, zero formal proofs, and zero empirical benchmarks. The entire evaluation is based on documentation analysis of the four protocols' specifications.

What could have been bounded: protocol composition overhead (latency/throughput when chaining MCP→ACP→A2A), discovery convergence time for ANP's decentralized registry, security attack surface area as a function of exposed endpoints per protocol layer.

6 checks:

1. Reproducibility of claims: All claims traceable to official protocol documentation ([6][9][10][11]) — reproducible by reading specs
2. Comparison completeness: 11 comparison dimensions cover architecture, transport, security, session, discovery — comprehensive for qualitative analysis
3. Historical accuracy: Timeline (Table 2) correctly sequences KQML(1993) → FIPA-ACL(2000) → SOA(2002) → RAG(2020) → Function Calling(2023) → protocols(2024-25)
4. Security model structure: Threat analysis uses consistent lifecycle phases across all four protocols, enabling cross-comparison
5. Roadmap logical ordering: MCP→ACP→A2A→ANP sequences by increasing decentralization and trust boundary expansion — internally consistent
6. Limitation acknowledgment: Table 7 explicitly lists limitations for each protocol (prompt injection risk for MCP, registry dependency for ACP, enterprise-centricity for A2A, negotiation overhead for ANP)

§5 实验与数据 #

This survey contains no empirical experiments. The analytical contribution is the comparative evaluation in Table 7 and the per-protocol security analysis.

Primary Comparison (Table 7) #



Paper's Table 7, verbatim (caption: "Comparison of MCP, ACP, A2A, and ANP Protocols"). The 11-dimension comparison constitutes the paper's primary analytical contribution. Key differentiators: MCP is the only protocol with Stdio transport (local-first); ACP is unique in MIME-typed multipart messages; A2A uniquely uses capability-based Agent Cards for discovery; ANP alone provides DID-based trustless identity.

Security Threat Models #



Paper's Table 3, verbatim (caption: "Threats and Mitigation Strategies Across the MCP Lifecycle"). MCP has the most extensive threat surface with 14 identified threats across Creation/Operation/Update phases. Notable: Tool Poisoning (malicious prompts influencing LLM behavior), Cross-Server Shadowing (one server overrides another's tool references), and Tool Redefinition ("rug pull" after initial validation).



Paper's Table 4, verbatim (caption: "A2A Lifecycle Security Challenges and Mitigation Strategies"). A2A's security model is lighter (5 threats), reflecting its enterprise-trust assumption. The unique A2A threat is Push Notification Hijacking via spoofed SSE endpoints.

Protocol Evolution Timeline #



Paper's Figure 2, verbatim (caption: "Timeline of Interoperability"). Three evolutionary phases visible: Symbolic/SOA Foundations (1993–2006), Retrieval and In-Model Action (2020–2023), Protocol-Oriented Interoperability (2024–2025). The 17-year gap between ESB (2006) and RAG (2020) reflects the "LLM revolution" inflection point.

Key Findings Summary #

Dimension	MCP	ACP	A2A	ANP
Architecture	Client–Server	Brokered	Peer-like	Decentralized P2P
Discovery	Manual/static URL	Registry-based	Agent Card (HTTP GET)	Search engine
Auth	Token-based + optional DID	Bearer/mTLS/JWS	DID handshake	W3C DID (did:wba)
Transport	HTTP/Stdio/SSE	HTTP + streams	HTTP + SSE + Push	HTTPS + JSON-LD
Session	Stateless + optional context	Session-aware	Session-aware or stateless	Stateless (DID tokens)
Weakness	Centralized + prompt injection	Registry required	Enterprise-centric	High negotiation overhead

§6 论证链 #

Step	Claim	Evidence	Paper §§
1	Agent interoperability is fragmented: ad-hoc integrations cannot scale	Prior surveys focus on workflows, not underlying protocols; function-calling ecosystems have static tool registries and framework-specific auth	§1, §3.4
2	Four challenges map to four distinct interoperability layers	Context standardization (MCP), messaging barriers (ACP), collaboration standards (A2A), internet-agnostic communication (ANP) — each requires different trust model and scope	§2, Fig 1
3	Each protocol addresses one layer with a distinct architecture	MCP: JSON-RPC client–server for tools; ACP: brokered registry for typed messages; A2A: Agent Cards for task delegation; ANP: DID+JSON-LD for P2P	§4–7
4	Protocols share lifecycle structure but differ in security posture	All use Creation/Operation/Update/Termination phases; MCP has 14 threats (broadest surface), ANP has fewest but hardest to mitigate (DID spoofing)	§4.6, §5.5, §6.3, §7.4
5	No single protocol covers all dimensions	Table 7 shows each protocol excels in its target scope but has explicit limitations outside that scope	§8, Table 7
6	Complementary phased adoption is the practical path	MCP (foundation) → ACP (messaging) → A2A (enterprise) → ANP (open market), ordered by maturity and integration complexity	§9

§7 实现 cross-reference #

[实现未公开]

This is a survey paper analyzing protocol specifications rather than proposing a new implementation. The surveyed protocols have open specifications:

• MCP: modelcontextprotocol.io (Anthropic, JSON-RPC spec)
• A2A: google.github.io/A2A/ (Google, Agent Card + Task spec)
• ACP: docs.beeai.dev (IBM BeeAI, RESTful HTTP spec)
• ANP: github.com/agent-network-protocol (community, DID + ADP spec)

No reference implementation accompanies this survey itself.

关键实现细节 #

1. Discovery endpoint convention: All four protocols converge on /.well-known/ paths for agent metadata (A2A: agent.json, ACP: agent.yml, ANP: agent-descriptions), suggesting a de facto standard even without formal cross-protocol agreement.
1. JSON-RPC 2.0 as common substrate: MCP, A2A, and ANP all use JSON-RPC 2.0 as their RPC layer, while ACP uses RESTful HTTP. This means 3/4 protocols share wire format semantics — a potential bridging point the paper does not explore.

核心技术壁垒 (expanded) #

The fundamental unsolved problem is protocol composition: how does an agent simultaneously participate in MCP (as a tool provider), ACP (as a message receiver), A2A (as a skill executor), and ANP (as a discoverable peer)? The paper proposes phased adoption but provides no architecture for a single agent runtime that implements all four protocol interfaces, handles conflicting auth models (token vs. mTLS vs. DID), and manages the resulting state explosion across four independent lifecycle models.