The Six Key AI Agent Protocols Explained: MCP, A2A, UCP, AP2, A2UI, and AGUI

Introduction: Why Do AI Agents Need Protocols?

AI agents, on their own, are actually quite limited. Give one a simple set of instructions and a few tools, and it can answer questions or call a tool or two. But when you need it to collaborate with other systems, process payments, or stream results in real time, it hits a wall.

Traditional APIs assume there's a human on the other end — someone who can click a "Buy" button, browse a product catalog, or fill out a form. But an AI agent doesn't know how to check out, has no catalog to browse, and can only generate text. In a recent technical talk, Chris Overholt, a Developer Relations Engineer at Google Cloud, systematically walked through how six protocols address these problems one by one.

This article uses a kitchen management agent (one that orders ingredients from wholesalers for a restaurant) as a running example, built with Google's open-source Agent Development Kit (ADK). We'll incrementally add protocols, evolving the agent from one that "makes up data" into a complete system capable of querying real inventory, placing orders, authorizing payments, and displaying interactive dashboards in real time.

MCP: Model Context Protocol — Connecting Agents to Tools and Data

The Core Problem MCP Solves

Agents need to use external tools, but if every API endpoint requires a custom tool definition, you'll end up managing dozens of tools across just a few services. That doesn't scale — for developers or for the agent.

How MCP Works

MCP (Model Context Protocol) lets an agent connect to an MCP server, which dynamically exposes available tools at runtime. Instead of hardcoding tool definitions, you simply point to an MCP server, and the agent automatically discovers what capabilities are available.

Background: MCP's Path to Standardization MCP was officially open-sourced by Anthropic in November 2024 and quickly became the de facto standard for AI tool integration. Its design was inspired by the Language Server Protocol (LSP) — proposed by Microsoft, LSP unified the communication between code editors like VS Code and various language tools (such as code completion and syntax checking), enabling a single language plugin to serve all LSP-compatible editors without separate development for each one. MCP takes the exact same approach: it defines a standardized client-server communication specification that allows any AI model to invoke any external tool or data source in a uniform way, completely decoupling models from tools. Before MCP, every AI application needed bespoke "tool definition" code for each external service, with maintenance costs growing linearly with the number of tools. After MCP, tool developers simply publish an MCP server, and all compatible models can automatically connect.

For the kitchen management agent, this means connecting to three MCP servers: the inventory database, recipes and operational procedures, and supplier emails. In ADK, each server requires just three lines of code using MCP Toolset — no API call code needed.

MCP's core value lies in the prototyping phase — when you're still exploring what an agent can do, MCP lets you rapidly plug in new data sources, observe how the agent uses them, and then optimize from there.

A2A: Agent-to-Agent Protocol — Cross-Team Expertise Collaboration

The Core Problem A2A Solves

The kitchen management agent can check inventory, but it doesn't know today's wholesale prices, supplier quality ratings, or delivery time windows. That knowledge is scattered across different agents built by different teams using different frameworks.

How A2A Works

A2A (Agent-to-Agent Protocol) solves this through a standardized agent discovery mechanism. Each agent provides an "Agent Card" at a known URL, describing its capabilities. Your agent fetches these cards, discovers what each specialist can do, and then communicates via send message.

Background: A2A's Roots in Microservices Architecture A2A was released by Google in April 2025 as a communication standard designed specifically for multi-agent systems. The best analogy for understanding A2A is the Service Registry & Discovery mechanism in microservices architecture — in a microservices system, each service registers its address and capabilities with a registry (like Consul or Eureka) at startup, and other services find collaborators by querying the registry instead of hardcoding addresses. A2A's "Agent Card" plays exactly this role, but designed for AI agents: cards describe not just a service address, but also the agent's domain expertise, supported task types, and interaction modes in natural language. Built on HTTP/JSON-RPC, A2A supports three communication modes — synchronous requests, asynchronous tasks, and streaming responses — with built-in authentication to ensure secure cross-organization, cross-framework agent collaboration. This means a pricing agent built with LangChain and a logistics agent built with ADK can collaborate seamlessly through A2A, with zero framework-level adaptation.

In ADK, you can expose any agent as an A2A service with a single line of code using the to_a2a method. On the discovery side, you simply point to a remote agent's URL, fetch the card, and send a message. The agent doesn't need to know how the remote agent was built, or even what framework it runs on.

In practice: when you ask "What's the price on salmon? What's the quality rating? Can it arrive by 5 PM today?" the agent automatically routes each question to the right specialist (pricing, quality, logistics) without knowing any of their implementation details.

UCP: Universal Commerce Protocol — Structured Business Transactions

The Core Problem UCP Solves

The agent needs to place orders, but while humans can browse storefronts, agents need machine-readable merchant information and product discovery capabilities.

How UCP Works

UCP (Universal Commerce Protocol) standardizes the process of merchant discovery, order placement, and order tracking. It provides a structured product catalog via a /.well-known/ucp endpoint, and agents can send structured checkout requests containing item details, quantities, and payment information.

Background: The /.well-known Endpoint Convention The /.well-known/ path used by UCP is a standard convention defined by the Internet Engineering Task Force (IETF) in RFC 5785, specifically for hosting "well-known" metadata files. You may already be familiar with this pattern: /.well-known/openid-configuration is used for OAuth authentication discovery, and /.well-known/security.txt is used for security vulnerability disclosure. UCP follows this convention, meaning any UCP-supporting merchant only needs to deploy a standard JSON file under its domain, and AI agents can automatically discover its product catalog and transaction rules without any additional integration work. This "convention over configuration" design philosophy keeps UCP's adoption cost extremely low while maintaining high interoperability.

No browsing websites, no parsing HTML, no guessing checkout flows. Everything is standard HTTP requests following the UCP specification. Typed request formats mean the agent doesn't have to guess what a checkout request should look like.

AP2: Agent Payments Protocol — Authorization and Auditing

The Core Problem AP2 Solves

UCP lets agents place orders, but who authorized the spending? There's no audit trail, no spending limits, no approved merchant list.

How AP2 Works

AP2 (Agent Payments Protocol) introduces typed "Mandates":

• Checkout Mandate: Defines guardrails, such as which merchants are approved and what can be purchased
• Payment Mandate: Enforces spending limits, specifies approved payment methods, and records user authorization
• Signed Receipts: Create a complete audit trail

Background: From "Prompt Constraints" to "Cryptographic Contracts" — A Trust Upgrade AP2's design philosophy originates from the financial sector's Principle of Least Privilege and draws on two mature technical paradigms: first, OAuth 2.0's delegated authorization model — users don't hand their passwords directly to third-party apps; instead, they issue a permission-limited "token" that precisely defines what the app can and cannot do. Second, the banking concept of a Standing Order — pre-set automatic payment rules enforced by the banking system, rather than relying on the payer to comply voluntarily each time. AP2 merges both approaches, elevating spending rules from "natural language constraints in prompts" (e.g., "You should not spend more than $500") to "cryptographically verifiable, typed contracts." The former relies on the model's "understanding" and "compliance" and risks being bypassed or misinterpreted; the latter is enforced at the protocol level, making any violating transaction technically impossible. Signed receipts introduce non-repudiation — every transaction has a complete chain-of-authorization proof, meeting enterprise-grade compliance audit requirements.

Practical configuration example: a restaurant owner can set rules like "only purchase from these approved suppliers," "auto-approve orders under $500 on the company card," and "orders over $500 require manager sign-off." When the agent tries to buy from an unauthorized supplier, the mandate rejects it; when it places a legitimate order, it receives a signed receipt with a complete authorization chain.

The key distinction: rather than telling the agent in its instructions "don't spend more than $500" and hoping it complies, the constraint is enforced at the protocol level — structurally and cryptographically.