AI Agent Protocols Explained: MCP, A2A, ACP & More

An AI agent is only as useful as the systems it can reach. In production, a single agent may need your CRM, a document store, a ticketing system and a second agent owned by another team. Each of those connections traditionally needs its own wrapper, auth flow, schema and error handling.

That integration cost is growing fast. Gartner predicts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025.

AI agent protocols exist to stop every team from rebuilding the same plumbing. This guide explains what each major protocol does, where it sits in the stack, how mature it is, and how to choose between them.

Key Takeaways

• MCP connects an agent to tools and data. A2A connects one agent to another. Most production systems need both.
• Both protocols now sit under the Linux Foundation’s Agentic AI Foundation: MCP since December 2025 and A2A since August 2026.
• “ACP” names two different protocols. IBM’s Agent Communication Protocol merged into A2A in August 2025. OpenAI and Stripe’s Agentic Commerce Protocol is a separate, active commerce standard.
• Commerce and payment protocols (UCP, Agentic Commerce Protocol, AP2, x402) build on MCP and A2A rather than replacing them.
• Pick a protocol by interaction boundary, not popularity. A conventional API is still the right tool for fixed, deterministic service calls.

What Are AI Agent Protocols?

AI agent protocols are open specifications that define how agents discover capabilities, exchange context, delegate work and call external systems. They give every participant in an agentic system the same contract, so a new tool or agent can plug in without custom glue code.

Agent communication protocols cover four kinds of boundary: agent to tool, agent to agent, agent to user interface, and agent to commerce or payment systems. Each protocol in this guide targets one or two of those boundaries.

How Agent Protocols Differ From APIs

An API exposes one service with a fixed request and response shape. A developer reads its documentation and writes code against it.

An agent protocol sits one level up. It tells an agent at runtime which capabilities exist, what inputs they take, and how to track long-running work. Protocols do not replace APIs. An MCP server, for example, typically wraps an existing REST API and describes it in a form a model can select and call.

The N×M Integration Problem

Without a shared protocol, connecting N agents to M systems can require up to N × M custom integrations. Every new model, framework or vendor multiplies the work.

A protocol turns that into roughly N + M: each agent implements the client side once, and each system implements the server side once. That is the core economic argument for standardization, and it is why the major AI vendors have moved their protocols into neutral, open governance.

The AI Agent Protocol Stack

The easiest way to understand AI agent protocols is as a stack of layers, each owning one interaction boundary. No single protocol covers the whole stack, and most are designed to be combined.

Layer	Boundary it governs	Main protocols
User interface	Agent ↔ frontend application	AG-UI, A2UI
Agent collaboration	Agent ↔ agent	A2A, NLIP
Tools and context	Agent ↔ tools, data, prompts	MCP
Network and identity	Agent ↔ open network	ANP
Commerce and payments	Agent ↔ merchant, payment rail	UCP, Agentic Commerce Protocol, AP2, x402

Identity, authorization, observability and audit logging are not a layer of their own. They cut across every layer, and each protocol handles them slightly differently.

Model Context Protocol (MCP)

The Model Context Protocol is the open standard for connecting AI applications to external tools, data and reusable prompts. Anthropic released it in November 2024 and donated it to the Linux Foundation’s Agentic AI Foundation (AAIF) on December 9, 2025. At the time of the donation, the MCP project reported over 97 million monthly SDK downloads and 10,000 active servers.

Host, Client and Server

MCP defines three roles:

• Host: the AI application the user works in, such as an IDE, an assistant or an enterprise agent platform.
• Client: a connector inside the host that holds the link to one MCP server. A host can run many clients.
• Server: a program that exposes capabilities from an underlying system, such as a database, SaaS tool or file store.

The model never talks to a server directly. The host decides which capabilities to show the model and executes the calls it chooses.

Tools, Resources and Prompts

Servers expose three primitives. Tools are actions the model can invoke, each with a name, description and JSON Schema for its inputs. Resources are read-only context the application can load, such as documents or records. Prompts are reusable instruction templates for common tasks.

A minimal tool definition looks like this:

{
  "name": "create_support_ticket",
  "title": "Create Support Ticket",
  "description": "Opens a helpdesk ticket for a verified customer.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string" },
      "priority": { "type": "string", "enum": ["low", "normal", "high"] },
      "summary": { "type": "string", "maxLength": 200 }
    },
    "required": ["customer_id", "summary"]
  }
}

The description and schema are what the model reads to decide whether and how to call the tool. Vague names and loose schemas are the most common cause of wrong tool selection.

Transport and the 2026-07-28 Specification

MCP messages use JSON-RPC 2.0. Local servers usually run over standard input/output (stdio), while remote servers use Streamable HTTP.

The current specification revision is 2026-07-28. Its headline change is a stateless protocol core: each request carries its own protocol version and client capabilities, so remote servers can run behind ordinary load balancers without sticky sessions. The same revision deprecates three older client features (roots, sampling and logging) and tightens the authorization spec to match real-world OAuth 2.0 and OpenID Connect deployments.

Security Considerations

MCP defines how authorization works, but it does not decide what an agent should be allowed to do. That remains your policy. Treat every third-party MCP server as a separate trust boundary, issue scoped credentials per server, and restrict write and admin tools more tightly than read-only ones. Tool descriptions and outputs from untrusted servers should be treated as untrusted input to the model.

Limitations

MCP standardizes access; it does not plan, reason or orchestrate. The agent still needs its own logic to decide which tools to call and in what order. Large tool catalogs also hurt accuracy, because the model has more options to choose from and more context to read. Exposing a curated set of well-described tools usually outperforms wrapping every endpoint, which is a design decision we make early in any engagement of our AI development services.

Agent2Agent Protocol (A2A)

The A2A protocol is the open standard for agent-to-agent communication between independent, potentially opaque agents. Google launched it in April 2025 and donated it to the Linux Foundation. In April 2026, the Linux Foundation reported more than 150 supporting organizations, including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow. A2A became a hosted project of the Agentic AI Foundation in August 2026, placing it alongside MCP.

As of now, the latest released specification is version 1.0.0.

Agent Cards

Every A2A agent publishes an Agent Card: a JSON document describing its identity, skills, endpoints and authentication requirements. A client reads the card before sending any work, so it never needs hard-coded knowledge of the remote agent.

A simplified Agent Card looks like this:

{
  "name": "Supplier Quote Agent",
  "description": "Returns price and lead-time quotes for catalog items.",
  "version": "1.2.0",
  "supportedInterfaces": [
    { "url": "https://quotes.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }
  ],
  "capabilities": { "streaming": true, "pushNotifications": true },
  "defaultInputModes": ["application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    { "id": "quote", "name": "Request quote",
      "description": "Quotes unit price and delivery date for a SKU and quantity.",
      "tags": ["procurement", "pricing"] }
  ]
}

Production cards also declare security schemes (OAuth 2.0, OpenID Connect, API key or mutual TLS). The spec supports signed Agent Cards and an authenticated extended card that reveals extra skills only after the client logs in.

Task Lifecycle

A client sends a message. The remote agent either replies directly or creates a Task, a stateful unit of work with its own ID. Tasks move through defined states:

• Active: TASK_STATE_SUBMITTED, TASK_STATE_WORKING
• Interrupted: TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED
• Terminal: TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, TASK_STATE_REJECTED

Results come back as Artifacts made of text, file or structured-data parts. A contextId groups related tasks into one conversation, which makes multi-turn delegation possible.

Transport Bindings and Updates

A2A separates its data model from its transport. The spec defines three standard bindings: JSON-RPC, gRPC and HTTP+JSON/REST. Clients receive progress by polling, by streaming, or through push notifications to a webhook, which suits tasks that run for minutes or hours.

Security Model

A2A relies on standard web security rather than inventing its own. Every request is authenticated against the schemes in the Agent Card, and the spec requires servers to scope task visibility to the authenticated client. Push-notification webhooks must be authenticated too, since they are an inbound path into your systems.

Limitations

Every remote agent is another distributed dependency, with its own availability, latency and versioning. Cross-organization workflows also need agreed data-sharing rules and clear task ownership, which the protocol does not provide. Teams planning multi-agent systems should design these boundaries before adding agents; it is the first workstream in our AI agent development practice.

What Happened to ACP?

“ACP” refers to two unrelated protocols, and many articles still mix them up.

IBM’s Agent Communication Protocol came out of the BeeAI project in March 2025 as a REST-based way for agents to exchange multimodal messages. In August 2025, IBM and the Linux Foundation merged it into A2A. The ACP repository was archived, and BeeAI itself now uses A2A adapters, as IBM’s own tutorial notes.

The Agentic Commerce Protocol is a different standard. OpenAI and Stripe co-developed it to power Instant Checkout in ChatGPT, launched in September 2025. Stripe describes it as an open-source, Apache 2.0 licensed standard for programmatic commerce between buyers, AI agents and businesses.

Name	Purpose	Status
Agent Communication Protocol (IBM/BeeAI)	General agent-to-agent messaging over REST	Merged into A2A (Aug 2025); repo archived
Agentic Commerce Protocol (OpenAI/Stripe)	Agent-driven checkout and purchasing	Active, open source

For new architecture work, treat IBM’s ACP as historical and plan agent-to-agent communication on A2A. Treat the Agentic Commerce Protocol as a commerce-layer option alongside UCP.

Other AI Agent Protocols Worth Knowing

MCP and A2A cover the core of most agent systems. The protocols below handle the edges: open networks, user interfaces, commerce and payments. Their maturity varies widely, so check each one’s status before committing.

Agent Network Protocol (ANP)

ANP is an open-source, community-led protocol for agents that need to find and trust each other on the open internet without a central registry. It uses W3C Decentralized Identifiers (DIDs) for identity and JSON-LD for capability descriptions. Its repository describes three layers: identity and encrypted communication, a meta-protocol for negotiating how agents talk, and an application layer for describing capabilities.

AG-UI (Agent-User Interaction Protocol)

AG-UI, led by CopilotKit, connects an agent backend to a user-facing application through a stream of events: messages, tool calls and state changes. It is the runtime link that lets a frontend show what an agent is doing in real time. CopilotKit notes that AG-UI is not a UI spec itself; it carries UI specs between agent and app.

A2UI

A2UI is a declarative generative UI specification that originated at Google. An agent uses it to return interface components, such as forms, cards or approval screens, as structured data the client renders natively. A2UI and AG-UI are complementary: A2UI describes what to show, AG-UI delivers it.

Universal Commerce Protocol (UCP)

Google announced UCP at NRF on January 11, 2026, developed with partners including Shopify, Etsy, Wayfair, Target and Walmart. It standardizes the shopping journey from product discovery through checkout and order management. Merchants can expose UCP through a REST API, an MCP server or A2A, and it is designed to work with AP2 for payments.

Agent Payments Protocol (AP2)

AP2, announced by Google in September 2025 with more than 60 partner organizations, answers one question: how does a merchant know an agent is authorized to spend? It uses three cryptographically signed mandates (Intent, Cart and Payment) carried as verifiable credentials. AP2 is payment-method agnostic and works as an extension of A2A and MCP.

x402

x402 revives the long-unused HTTP 402 “Payment Required” status code so an agent can pay for an API call or resource inside the request itself. Coinbase launched it in May 2025, and Coinbase and Cloudflare co-founded the x402 Foundation in September 2025. It settles in stablecoins and suits machine-to-machine micropayments rather than retail checkout.

Natural Language Interaction Protocol (NLIP)

NLIP is the only protocol here published by a formal standards body. Ecma International approved ECMA-430 in December 2025, with companion standards binding it to HTTP, WebSocket and AMQP. It defines an application-level envelope for natural-language exchanges between humans and agents or between agents. Its ecosystem is still early.

FIPA ACL

The Foundation for Intelligent Physical Agents’ Agent Communication Language predates LLMs by two decades. It defined structured performatives for multi-agent research systems. It is useful history but was not designed for tool calling, web-native transport or modern model-based agents.

AI Agent Protocol Comparison

MCP and A2A are the only two protocols with broad production adoption and neutral foundation governance. Everything else is either specialized, early, or both.

Protocol	Layer	Backed by	Transport	Discovery	Maturity	Best for
MCP	Agent ↔ tools/data	Agentic AI Foundation (from Anthropic)	JSON-RPC over stdio or Streamable HTTP	Server capability listing	Mature	Connecting agents to CRM, ERP, databases, files
A2A	Agent ↔ agent	Agentic AI Foundation (from Google)	JSON-RPC, gRPC, HTTP+JSON/REST	Agent Cards	Mature (v1.0)	Delegating tasks between independent agents
ANP	Agent ↔ open network	Open-source community	HTTP-based	DIDs + JSON-LD descriptions	Developing	Cross-organization agents without a central registry
AG-UI	Agent ↔ UI	CopilotKit + ecosystem	Event stream (HTTP/SSE, others)	Client-defined	Developing	Streaming agent activity into a frontend
A2UI	Agent ↔ UI	Google	Carried by AG-UI or A2A	Client capabilities	Emerging	Agent-generated forms, cards, approvals
UCP	Agent ↔ merchant	Google + retail partners	REST, MCP or A2A	Merchant capability profile	Emerging	Product discovery, checkout, orders
Agentic Commerce Protocol	Agent ↔ merchant	OpenAI + Stripe	HTTP APIs	Merchant integration	Active	In-chat checkout (e.g. ChatGPT)
AP2	Agent ↔ payment system	Google + 60+ partners	Extension of A2A/MCP	Payment capabilities	Active	Proving a purchase was user-authorized
x402	Agent ↔ paid service	x402 Foundation (Coinbase, Cloudflare)	HTTP 402	Per-request payment terms	Emerging	Pay-per-call APIs and data
NLIP	Agent ↔ agent/human	Ecma International (ECMA-430)	HTTP, WebSocket, AMQP	Not specified	Developing	Standards-body natural-language exchange
IBM ACP	Agent ↔ agent	—	REST	—	Archived	Historical reference only; use A2A

MCP vs A2A: When to Use Which

Use MCP when an agent needs to use a capability. Use A2A when an agent needs to hand work to another agent that reasons on its own. The question is not which protocol is better, but which boundary you are crossing.

If you need to…	Use	Why
Call a fixed internal service with known inputs and outputs	Conventional API	No discovery or reasoning needed; a protocol adds overhead
Let an agent query a database, CRM or document store	MCP	Structured, discoverable tool access with schemas
Let an agent take actions in a SaaS tool (create ticket, update record)	MCP	Tools with typed inputs and scoped permissions
Hand a multi-step job to a specialist agent owned by another team	A2A	Task lifecycle, streaming updates, opaque execution
Coordinate with an agent from a different vendor or company	A2A	Shared discovery via Agent Cards, standard auth
Build an orchestrator that delegates and each delegate uses tools	MCP + A2A	A2A between agents, MCP inside each agent
Stream agent progress into your web app	AG-UI	Built for agent-to-frontend events
Let an agent complete a purchase	UCP or Agentic Commerce Protocol, plus AP2	Commerce flow plus provable payment authorization

A practical test: if the thing on the other side has its own model, memory and judgment, it is an agent and A2A fits. If it does what it is told and returns a result, it is a tool and MCP fits.

Worked Example: A Procurement Request, End to End

One workflow shows how the protocols divide the work. A plant manager types: “We’re low on M8 bolts. Reorder 5,000 from an approved supplier, delivery within 10 days.”

1. User → orchestrator (AG-UI). The request arrives from the procurement web app. AG-UI streams the orchestrator’s progress back to the screen as it works.
2. Orchestrator → ERP (MCP). The orchestrator calls an MCP tool, get_inventory, to confirm current stock, then list_approved_suppliers to get vendors cleared for that part.
3. Orchestrator → policy store (MCP). It reads a resource holding the purchasing policy: orders above a set value need human approval.
4. Orchestrator → supplier agents (A2A). It fetches each supplier’s Agent Card, checks the quote skill, and sends a message to three supplier agents in parallel. Each creates a Task and moves to TASK_STATE_WORKING.
5. Supplier agents → orchestrator (A2A). Quotes stream back as Artifacts with structured data: unit price, delivery date, terms. One supplier returns TASK_STATE_INPUT_REQUIRED asking for the delivery site; the orchestrator answers in the same contextId.
6. Orchestrator → user (AG-UI + A2UI). The order exceeds the approval threshold. The orchestrator renders an approval card comparing the three quotes. The manager approves the cheapest option that meets the 10-day window.
7. Orchestrator → ERP (MCP). It calls create_purchase_order with an idempotency key, so a retry can never create a duplicate order.
8. Orchestrator → supplier (A2A). It sends the confirmed PO to the chosen supplier agent, which completes the task with an order confirmation artifact.

Hop	Protocol	What crosses the boundary
App ↔ orchestrator	AG-UI (+ A2UI for the approval card)	User request, progress events, approval
Orchestrator ↔ ERP and policy	MCP	Tool calls and resources
Orchestrator ↔ supplier agents	A2A	Tasks, quotes, confirmations

No agent in this flow can see another agent’s prompts, tools or data. The orchestrator never touches a supplier’s systems, and suppliers never touch the ERP. If suppliers accepted agent payments, AP2 would add a signed Payment Mandate at step 8.

Security Checklist for AI Agent Protocols

Every protocol connection is a new access path into your systems. Protocols provide the hooks for authentication and authorization; your architecture decides how strict they are.

• Verifiable agent identity. Every agent and client has its own identity, never a shared service account. Use OAuth 2.0, OpenID Connect or mutual TLS as declared in the Agent Card or MCP server metadata.
• Least-privilege scopes. Grant each agent only the tools and data its task needs. Separate read, write, admin and payment permissions.
• Verify before you trust. Validate Agent Card signatures where available, confirm endpoints match the expected domain, and review third-party MCP servers before connecting them.
• Treat tool output as untrusted input. Documents, web pages and tool responses can carry prompt injection. Never let content from an external source silently trigger a high-impact action.
• Keep credentials out of the model’s context. Store secrets in a managed vault, use short-lived tokens, and rotate them on a schedule.
• Minimize data at each handoff. Pass only the fields the next agent needs. Re-check authorization at every A2A boundary.
• Human approval for high-impact actions. Payments, deletions, permission changes and external communications should wait for explicit sign-off.
• Authenticate inbound webhooks. A2A push notification endpoints accept traffic from outside; validate every request.
• End-to-end audit trail. Log user ID, agent ID, task ID, tool calls, approvals and outcomes so any action can be traced back to the request that caused it.
• Kill switches. Be able to revoke an agent’s credentials, disable a tool, cancel in-flight tasks and quarantine an agent within minutes.

These controls map closely to the requirements of ISO/IEC 42001 and the EU AI Act. Teams that need help formalizing them can work with our AI governance consulting team.

Common Implementation Mistakes

Most agent protocol projects that struggle do so because of architecture choices, not protocol gaps.

Mistake	What goes wrong	Fix
Treating MCP and A2A as competitors	Teams pick one and force it across boundaries it was not built for	Map each boundary first, then assign a protocol per boundary
Making every function an agent	Extra latency, model cost and failure points with no reasoning benefit	Keep deterministic steps as tools or plain services
Wrapping every API in MCP	Huge tool catalogs that confuse the model and cost tokens	Expose a curated set of task-level tools with tight schemas
Trusting discovery metadata blindly	A spoofed Agent Card or malicious MCP server gains access	Verify signatures, domains and authorization before first use
Ignoring idempotency and retries	Network retries create duplicate orders, tickets or payments	Use idempotency keys and bounded retries on every write
Coupling business logic to one spec version	A spec revision (like MCP’s 2026-07-28 stateless change) forces a rewrite	Put protocol code behind an adapter layer and pin versions

How to Roll Out an Agent Protocol Stack

Start with one workflow and one protocol, prove it in production, then widen. Cost and timeline depend far more on the number of systems, compliance needs and legacy readiness than on the protocols themselves.

1. Proof of concept. One workflow, one agent, two or three MCP servers in front of existing APIs. The goal is to validate tool design and data access, not scale.
2. Controlled pilot. Add authentication, scoped credentials, audit logging and human approvals. Run with a small user group on real data.
3. Production. Add observability, idempotency, retries, rate limits and version pinning. Introduce A2A only where a second, independent agent is genuinely needed.
4. Multi-agent scale. Add more specialist agents, cross-team Agent Cards, and, where relevant, AG-UI, commerce or payment protocols. Governance and ownership rules become the main workstream.

The main cost drivers are the number of systems to expose, the quality of existing APIs, security and compliance requirements, and how much custom UI the workflow needs.

The Future of AI Agent Protocols

The clearest trend is consolidation under neutral governance. MCP and A2A now share a home at the Agentic AI Foundation, and IBM folded its own protocol into A2A rather than compete. Fewer, better-governed standards make long-term bets safer for enterprises.

Three areas are still moving fast. Commerce and payments have several overlapping options (UCP, the Agentic Commerce Protocol, AP2, x402) that have not yet settled. Agent identity and trust on the open web, the problem ANP targets, remains unsolved at scale. And user-interface protocols such as AG-UI and A2UI are early but gaining framework support.

The practical takeaway: build on MCP and A2A now, keep protocol code behind adapters, and treat commerce, payment and UI protocols as pluggable choices you can swap as the market settles.

How Xicom Helps You Build Protocol-Ready Agent Systems

Choosing protocols is the easy part. Exposing the right capabilities, securing every boundary and keeping the system maintainable as specs evolve is where projects succeed or stall.

Xicom is an AI-first digital engineering company with 20+ years of enterprise software delivery, 750+ clients and 1,800+ projects across 50+ countries. Our teams design agent architectures, build MCP servers around existing enterprise systems, orchestrate multi-agent workflows over A2A, and put identity, audit and human-approval controls in place from day one.

We work under certified management systems, including ISO/IEC 42001 for AI management, ISO/IEC 27001 for information security, and SOC 2 Type II.

Whether you need a protocol-selection review or a production build, start a conversation with our AI consulting team or explore our generative AI development services.

FAQs