Protocols, from tools to agents to interfaces

• Book chapter
• Beginner
• 14 min read
• Checked 16 Aug 2026

In one sentence

MCP connects an AI application to capabilities, A2A lets one agent delegate work to another agent, and A2UI lets an agent describe a user interface that a client renders.

These protocols solve different boundaries. They can appear in one product without competing with one another.

What you will understand

Chapter	Question you will be able to answer
1. Boundary	Which two systems need a shared contract?
2. Complete request	How can MCP, A2A, and A2UI appear together?
3. Trust	What does each protocol leave to the application?
4. Simplicity	When is ordinary code the better choice?

Chapter 1: Begin with the two parties

Protocol	The two sides	Shared contract	Reach for it when
MCP	AI host or client ↔ capability server	Tools, resources, prompts, initialization, and protocol messages	An application needs controlled access to data or actions
A2A	A2A client ↔ remote agent	Agent discovery, messages, stateful tasks, artifacts, streaming, and authentication declarations	One agentic system delegates an outcome to another system
A2UI	Agent or server ↔ UI renderer	Surfaces, allowed component catalogs, data binding, updates, and user actions	The response should become an interactive native interface rather than text

The shortest memory aid is:

MCP  → “Which capability can my application call?”
A2A  → “Which remote agent can own this task?”
A2UI → “Which interface can the user see and operate?”

Chapter 2: Follow one passenger-care request

A passenger asks an airline assistant to review a disrupted flight and show the available options.

1. 01Host receives the passenger request
2. 02A2A delegates policy review to a remote passenger-care agent
3. 03That agent uses MCP tools to read the flight and policy systems
4. 04The remote agent returns findings and an artifact
5. 05A2UI describes the options panel
6. 06The client renders approved native components
7. 07A human reviews any consequential action

Chapter 3: A protocol describes a contract, not trust

Each protocol stops at its own boundary:

• The A2A Agent Card advertises the remote agent. It does not prove the agent deserves access to passenger data.
• An MCP tool definition describes a capability. It does not authorize the model or caller to use it.
• An A2UI action reports what the user selected. It does not approve a refund, booking, payment, or disclosure.

Authentication, authorization, policy, audit records, and human approval remain application responsibilities.

Chapter 4: Use ordinary code when it is enough

Use ordinary code when both sides live in one process and share one deployment. A protocol earns its cost when independently deployed systems need a stable contract, separate ownership, language neutrality, or trust-boundary controls.

Situation	Simpler choice
One Python service calls its own deterministic helper	A normal function
A fixed workflow invokes an internal library	A typed application interface
A frontend renders a UI your team already knows at build time	Normal frontend components
An external agent must be discovered and tracked across a long task	A2A may earn its place
An agent must send a portable interface to different renderers	A2UI may earn its place

Interview answer in 30 seconds

I choose the protocol from the boundary. MCP connects an AI host to tools, resources, or prompts exposed by a capability server. A2A lets one independently operated agent discover and delegate a stateful task to another agent. A2UI lets an agent describe a declarative interface that a trusted client renders with approved native components. These protocols can work together, but none of them replaces authentication, authorization, validation, approval, or audit controls.

Next: learn the A2A task and Agent Card model and the A2UI surface and catalog model.