Direct Answer

MCP, A2A, and A2UI solve three different interoperability problems. MCP 2026-07-28 lets a Host exchange context and invoke bounded Server capabilities. A2A 1.0 lets an A2A Client delegate and track work performed by an independently operated remote Agent. A2UI lets an Agent stream declarative UI state to a Renderer through a separately selected transport.

They are composable, not cumulative requirements. A system may use one, two, or all three, but every boundary keeps its own version, identity, authorization, state, failure, and audit contract.

Key Takeaways

  • MCP is not the Agent-to-Agent task protocol. Its current Core is stateless and exposes Tools, Resources, Prompts, Elicitation, and optional Extensions.
  • A2A 1.0 is not only JSON-RPC. Its canonical model and operations have JSON-RPC, gRPC, and HTTP+JSON/REST bindings with functional-equivalence requirements.
  • A2UI is not an execution authority. It describes ordered UI surfaces, components, data, and interactions that a product-owned Renderer validates.
  • Version each protocol independently. A2UI 0.9.1 is the current production release; A2UI 1.0 and its A2A extension remain Candidate specifications.
  • Discovery and schema validity do not grant permission. Authenticate principals and authorize objects, actions, destinations, and effects at the service that owns them.

Start with Boundaries, Not a "Complete Stack"

MCP, A2A, and A2UI define three useful boundaries. They are not mandatory layers, and composing them does not create transitive trust.

| Protocol and current status | Boundary | Stable contract | Still owned by the application | |---|---|---| | MCP 2026-07-28 | Host-to-Server capability exchange | stateless JSON-RPC Requests, per-request capabilities, Tools, Resources, Prompts, Elicitation, Extensions | user identity, object authorization, side-effect policy, model orchestration | | A2A 1.0.0 | Client-to-remote-Agent work delegation | Agent Card, Message, Task, Artifact, streaming, push notifications, multiple bindings | service trust, tenant isolation, business completion, callback safety | | A2UI 0.9.1 Current | Agent-to-Renderer UI state | ordered JSON envelopes, Surface, component catalog, data model, actions through a return channel | trusted rendering, accessibility, action authorization, data handling | | A2UI 1.0 Candidate | future A2UI contract | typed bidirectional function calls, revised catalogs, transport bindings | migration testing and explicit experimental opt-in |

A local function is preferable when one service owns the workflow. Use a remote task boundary when independent ownership or lifecycle handling has real value. Use a dynamic UI only when it improves a specific user task beyond text or a fixed product flow.

Pin What You Actually Deploy

Specifications, bindings, SDKs, extension formats, and examples evolve independently. Record the tested surface rather than pinning only a package version.

json 
{
  "mcp": {
    "revision": "2026-07-28",
    "transport": "streamable-http",
    "extensions": ["io.modelcontextprotocol/tasks"]
  },
  "a2a": {
    "version": "1.0",
    "binding": "HTTP+JSON/REST",
    "agent_card_digest": "sha256:..."
  },
  "a2ui": {
    "version": "0.9.1",
    "catalog_id": "https://example.com/catalog/v3",
    "catalog_digest": "sha256:..."
  },
  "runtime_revision": "immutable-release",
  "policy_revision": "policy-42"
}

Upgrade one dimension at a time through compatibility fixtures, failure tests, and a rollback plan. Do not silently send A2UI 1.0 envelopes to a 0.9.1 Renderer or assume an A2A binding from the presence of SSE.

Tool Boundary: Capability Is Not Permission

An MCP-like tool interface can describe names, inputs, and results. That helps interoperability; it does not allow a model, caller, or tool annotation to read an object or perform an external write.

For every invocation:

  1. obtain subject and tenant from trusted authentication middleware;
  2. validate the requested tool against an allowlist and a bounded schema;
  3. resolve target objects using server-side authorization;
  4. limit result bytes, rows, files, and outbound destinations;
  5. treat tool results as untrusted content before they enter a model or UI;
  6. require confirmation and idempotency for consequential effects.

Do not expose arbitrary SQL, shell commands, filesystem paths, or unrestricted HTTP fetches as generic Agent capabilities.

A2A Remote Task Boundary: Discovery Is Not Trust

A2A 1.0 separates a canonical data model and abstract operations from JSON-RPC, gRPC, and HTTP+JSON/REST bindings. It carries Messages, stateful Tasks, Artifacts, streaming updates, and optional push notifications between independently operated systems. The Agent Card advertises interfaces, capabilities, skills, and security schemes, but remains untrusted metadata until provenance is established.

Validate endpoint ownership, service identity, token audience and expiry, requested skill, tenant, target object, callback destination, and artifact access. A remote task must have durable state outside the model:

text 
accepted -> running -> waiting_for_input -> terminal
                         |                  |
                         +-> canceled       +-> succeeded | failed | rejected | outcome_unknown

Bind an idempotency key to the authenticated principal, tenant, action, and normalized parameters. A completed state is not proof that a payment, notification, or deletion happened exactly once.

A2UI Rendering Boundary: Presentation Is Not Authorization

A2UI can avoid arbitrary Agent-supplied UI code by letting a Renderer map an agreed component catalog to reviewed local components. Version 0.9.1 is the current production specification. Version 1.0 remains Candidate and changes envelopes, catalogs, theming, and function calls, so it requires an explicit migration path rather than automatic negotiation by name alone.

The rendering stream is ordered and stateful even when its carrier is not: createSurface precedes component and data updates, and deleteSurface terminates the surface. A transport must preserve message framing, order, metadata, and an interaction return channel when actions are enabled. A2UI can ride over A2A, AG-UI, MCP, SSE, WebSocket, or another binding; it is not itself the transport.

Reject payloads that exceed byte, depth, component, update-rate, URL, rich-text, image, or data-reference limits. Unknown components should render a product-owned fallback or be rejected. JSON Schema validates shape, not ownership, price, permission, or business truth.

The following dependency-free Go program validates the minimum identity and compatibility facts before an A2UI action can become an application proposal. SubjectID comes from authenticated runtime context; ActionToken is an opaque server-issued reference. Neither is authorization merely because it appears in a valid envelope.

go 
package main

import (
	"errors"
	"fmt"
)

type ProtocolProfile struct {
	MCPRevision string
	A2AVersion  string
	A2UIVersion string
	CatalogID   string
}

type Action struct {
	Name        string
	ActionToken string
	SubjectID   string
}

func validate(profile ProtocolProfile, action Action, trustedSubject string) error {
	if profile.MCPRevision != "2026-07-28" || profile.A2AVersion != "1.0" {
		return errors.New("unsupported_protocol_profile")
	}
	if profile.A2UIVersion != "0.9.1" {
		return errors.New("a2ui_candidate_not_enabled")
	}
	if profile.CatalogID == "" || action.SubjectID != trustedSubject {
		return errors.New("untrusted_identity_or_catalog")
	}
	if action.Name != "select_offer" || action.ActionToken == "" {
		return errors.New("invalid_action")
	}
	return nil
}

func main() {
	profile := ProtocolProfile{
		MCPRevision: "2026-07-28",
		A2AVersion:  "1.0",
		A2UIVersion: "0.9.1",
		CatalogID:   "https://example.com/catalog/v3",
	}
	action := Action{
		Name:        "select_offer",
		ActionToken: "offer-token-7",
		SubjectID:   "user-42",
	}
	fmt.Println(validate(profile, action, "user-42"))
}

Expected output is <nil>. This is a compatibility and input gate, not complete authorization. The effectful endpoint must resolve the opaque token and recheck the current object, tenant, confirmation binding, expiry, idempotency key, and business invariants immediately before execution.

A Safe Composition

A composition can be useful without becoming a rigid stack:

sequenceDiagram participant U as User participant H as Host Application participant R as Remote Service participant T as Owned Tool Service U->>H: Provides constrained intent H->>R: Authorized task request with idempotency key R->>T: Policy-checked tool request T-->>R: Bounded, untrusted result R-->>H: Durable task update or artifact reference H-->>U: Validated, accessible presentation

The host owns the user experience and action policy. The remote service owns its task state and its tool policy. Artifact references require authenticated retrieval; callback URLs are an SSRF boundary. Do not let model output choose unrestricted callback, tool, or UI destinations.

Failure, Privacy, and Accessibility

Define reconnection, cancellation, duplicate messages, timeout after an effect, ordering, backpressure, artifact expiry, deletion propagation, and outcome-unknown behavior before launch.

The UI contract must also include keyboard interaction, semantic labels, focus management after updates, contrast, localization, right-to-left layout, and a fixed fallback. Label Agent-generated content and reserve credentials, payment, and permission controls for product-owned components.

Log redacted correlation IDs, contract revisions, policy decisions, lifecycle classes, and latency. Do not default to retaining raw prompts, hidden reasoning, private artifacts, or full UI payloads.

Test the Composition

Test class Failure to demonstrate
Version and binding unsupported MCP revision, A2A binding mismatch, A2UI 1.0 envelope sent to a 0.9.1 Renderer
Authorization cross-tenant task, stale object, model-provided identity, transitive credential reuse
Task recovery duplicate request, reconnect gap, cancellation race, uncertain effect, push callback replay
Artifact safety oversized file, unsafe MIME type, expired reference, unauthorized download, SSRF callback
UI safety unknown catalog, missing component, unsafe URL, prompt-injected label, out-of-order update, payload flood
Accessibility keyboard-only flow, screen-reader update, focus after streaming changes, long translation
Upgrade old Client, schema mismatch, extension downgrade, catalog rollback, partial fleet deployment

Choose the smallest composition that passes these tests for representative user tasks.

FAQ

Is MCP required for every Agent tool?

No. A local function may be more appropriate. Use a protocol boundary when it provides a real interoperability or ownership benefit, while preserving server-side authorization and result limits.

Can a remote Agent send UI directly to the user?

Treat it as a proposal. A host renderer should validate and scope the payload, preserve product-owned controls, and route any action through the host's server-side policy.

Are protocol schemas security controls?

They are useful input validation controls. They do not authenticate a caller, determine object ownership, constrain external effects, or make generated content trustworthy.

Which A2UI version should a production system use?

Use A2UI 0.9.1 unless the deployment has explicitly opted into and tested the 1.0 Candidate. Version 1.0 changes message, catalog, theming, and function-call behavior, so treat it as a separate compatibility target until it becomes the current production release.

Can A2UI travel over A2A or MCP?

Yes. A2UI defines UI messages rather than one mandatory transport. It can be bound to A2A, MCP, AG-UI, or another carrier, but the chosen binding must preserve ordering, framing, metadata, capability negotiation, and an interaction return path. The carrier's authentication does not authorize the resulting UI action.

Further Reading

Primary Sources