Protocol Comparison

Summary

Six protocols on this page address different needs: MCP (tools/data), A2A (agent-to-agent), OpenAPI 3.1 (service APIs), Arazzo (multi-step workflows), ANP (decentralized identity), OASF (capability discovery). Commerce protocols (UCP, ACP) have their own section - see Agentic Commerce. Most systems layer MCP + A2A. Choose based on your architecture: vertical (tools), horizontal (peer agents), or workflow choreography.

Six protocols on this page have emerged to address different coordination problems in multi-agent systems, alongside commerce (UCP, ACP) covered separately. Most production systems use several simultaneously. Understanding what each one is for determines which combination your system needs.

The Full Landscape

Commerce protocols (UCP, ACP) are horizontal, agent-to-merchant protocols with their own auth (bearer tokens, mandates) and discovery (/.well-known/ucp, /.well-known/acp.json) conventions - see Agentic Commerce for the full treatment, including the "ACP" acronym-collision disambiguation this page used to carry.

What Each Protocol Is For

MCP - Give This Agent Tools

MCP answers the question: what can this agent do? It connects an agent to tools (functions it can call), resources (data it can read), and prompts (structured workflows), with negotiated extensions such as Tasks for long-running work. The connection is vertical - the agent reaches down into tools and data sources. 2026-07-28 is the current revision and all Tier 1 SDKs support it; 2025-11-25 is a compatibility target only where a client still requires it.

Use MCP when:

• An agent needs to call an API, run a function, or read a document
• You are exposing your service's capabilities to AI systems
• You want agents to be able to discover your tools at runtime
• You have long-running operations that need progress tracking

Many current agent frameworks support MCP. It is the baseline capability to evaluate when AI-enabled services need external tools or data. Streamable HTTP is the standard transport for remote non-stdio servers.

A2A v1.0.1 - Send This Task to the Specialist

A2A answers the question: which agent should handle this? It defines how one agent discovers a peer agent's capabilities, hands off a task with full context, and receives results back - including across organizational boundaries.

Use A2A when:

• The work requires a specialist that runs separately (different codebase, different organization)
• You need to dispatch tasks to multiple agents in parallel and aggregate results
• You want agents to discover each other at runtime via AgentCard (/.well-known/agent-card.json)
• Tasks are long-running and need streaming or callback-based progress

A2A and MCP cover different directions. An orchestrator agent might use A2A to delegate to a specialist, while that specialist uses MCP to call the actual APIs. Both protocols include patterns for long-running work, but they solve different coordination problems.

Commerce (UCP, ACP) - Buy This Thing on Behalf of the User

Agent-initiated purchases are a session-based commerce layer on top of the protocols above, not a variant of them - covered in full at Agentic Commerce, including UCP (most live merchant integrations), ACP (Beta, narrowing), and how each relates to MCP and A2A.

Arazzo - Here Is the Workflow Sequence

Arazzo answers the question: what is the right sequence of API calls for this intent? It is a machine-readable workflow specification layered on top of OpenAPI. Rather than exposing individual operations and letting agents figure out the sequencing, Arazzo describes the multi-step path explicitly.

Use Arazzo when:

• You have multi-step API workflows where the correct sequence is non-obvious
• You want to encode business workflows as first-class artifacts that agents can follow
• Your API has operations that must happen in a specific order (create order → confirm payment → dispatch)

Arazzo complements MCP: MCP exposes individual tools; Arazzo describes how those tools should be composed into workflows.

ANP - Decentralized Web Agent Identity

ANP (W3C AI Agent Protocol Community Group) answers the question: how does an agent prove its identity without a central authority? It uses Decentralized Identifiers (DIDs) for agent identity, JSON-LD for metadata, and end-to-end encryption for communication.

ANP is a draft specification. It addresses identity and trust in scenarios where agents from different organizations need to interact without a shared trust anchor. The practical maturity is low - production deployments should monitor the spec but not depend on it.

OASF - Capability Schemas and Marketplaces

OASF (Open Agent Schema Framework) answers the question: how do I describe what an agent or tool can do in a way that enables discovery and composition? It provides standardized schemas for capability description, enabling capability marketplaces where agents can search for tools by what they do rather than by who publishes them.

OASF is the discovery component of AGNTCY, a Linux Foundation multi-agent infrastructure project with Cisco, Dell, Google Cloud, Oracle, and Red Hat as formative members. The schema (v1.2.0) has not converged on a stable version and the marketplace tooling is not mature, but real multi-vendor governance sits behind it. It is worth tracking for teams building capability discovery infrastructure - see Emerging Standards for the full AGNTCY treatment.

Decision Guide

Work through these questions in order:

Does the agent need to call a function, read data, or use a prompt? Yes → MCP is the baseline. Implement MCP tools for every capability you want agents to access.

Does the work need to be handed to a different agent (specialist, external)? Yes → Add A2A. The orchestrating agent uses A2A to delegate; the specialist uses MCP to do the actual work.

Does the agent need to complete a purchase? Yes → Check the commerce platform and target host first. Use a supported hosted checkout handoff or a compatible UCP/ACP integration; MCP tool access alone does not establish payment or order support. See Agentic Commerce.

Does the workflow have a defined multi-step sequence that agents should follow? Yes → Add Arazzo. Write workflow definitions for your key user journeys.

Do agents need to prove identity without a central authority? Yes, in a research or emerging deployment → Monitor ANP. Not production-ready.

Do you need a marketplace for capability discovery? Yes, at scale → Contribute to and monitor OASF, the discovery component of AGNTCY (Linux Foundation). Not mature enough to build on.

How These Protocols Compose

A complete multi-agent system for a travel booking use case might look like this:

User
  │
  ▼
Travel Orchestrator (Agent)
  │
  ├── MCP → calendar-mcp        (read user's availability)
  ├── MCP → preferences-mcp     (read user's travel preferences)
  │
  ├── A2A → Flight Specialist Agent
  │           └── MCP → flight-search-mcp
  │           └── MCP → flight-booking-mcp
  │
  ├── A2A → Hotel Specialist Agent
  │           └── MCP → hotel-search-mcp
  │           └── MCP → hotel-booking-mcp
  │
  └── UCP/ACP → ACME Travel Commerce    (purchase flights and hotels)

The orchestrator uses MCP directly for its own data needs. It delegates specialist work via A2A. The final purchase goes through a commerce protocol (see Agentic Commerce). Arazzo workflow definitions describe the correct booking sequence (flights before hotels, confirmation before payment).

Maturity Considerations

When evaluating a protocol for production use, the spec stability matters less than SDK and tooling support. A stable spec with no SDKs requires you to implement the wire format yourself. MCP and A2A both have mature, actively maintained SDKs across multiple languages.

Decision Checklist

1. Does the agent need tools/data/prompts? → MCP (always)
2. Multi-agent delegation across teams? → A2A (add to MCP)
3. Agent-initiated purchases? → Platform/host commerce support (hosted checkout or a compatible UCP/ACP integration)
4. Complex multi-step API workflows? → Arazzo (layer on OpenAPI)
5. Decentralized agent identity needed? → ANP (draft; monitor)
6. Capability marketplaces? → OASF/AGNTCY (early; monitor)

Spec References

• MCP 2026-07-28 specification and release summary
• A2A v1.0.1
• OpenAPI 3.1
• Arazzo 1.1.0

Related Pages

• MCP Protocol - full MCP specification coverage
• A2A Protocol - agent-to-agent delegation
• Agentic Commerce - UCP, ACP, payments, and trust and risk
• Emerging Standards - ANP, OASF, agents.json, NLWeb, and what is coming next