Overview
Compare protocols by purpose, client data required, Akii support type, output/export, safety limitations, and official source.
- Readiness is not certification.
- Payment execution is not supported by Akii.
- Protocol pages link to official sources.
- Akii separates profile output, read-only tool access, readiness checks, action handoffs, and UI payload exports.
Comparison rules
The table distinguishes purpose, data required, Akii support type, current support status, output/export, safety limitations, and official source.
How to read support status
Supported means Akii has implemented the related product or output surface. Readiness means Akii checks whether client data and handoff paths are prepared for a protocol-style flow. Export means Akii can produce scoped output where configured. Planned and watchlist entries must not be sold as live support.
Where partners should start
Partners should begin with the protocol page for the surface they care about, then review the related publishing page and safety boundary. A partner evaluating commerce profiles should start with UCP. A tool integration should start with MCP. A protocol-readiness review should start with ACP, AP2, or the comparison table.
Claims boundary
Do not describe Akii readiness as third-party certification. Do not say Akii is formally partnered with a protocol owner unless the docs state that explicitly. Do not imply Akii processes payments, stores card data, stores payment tokens, or completes bookings. The comparison exists to make those boundaries visible before a page, report, or partner export is used.
Protocol matrix
| Protocol | Purpose | Client data required | Akii support type | Current status | Output/export | Safety limitations | Official source |
|---|---|---|---|---|---|---|---|
| OpenAI Agentic Commerce Protocol | Reduces ambiguity between an AI answer and the client checkout or approved action path. | Seller identity clarity; Products, services, offers, prices, availability, and policies; Checkout, deposit, booking, or provider handoff targets; Refund, cancellation, fulfillment, and customer-support rules | Akii prepares client data for ACP-style flows and payment-handoff readiness. | readiness | /docs/protocols/acp | Payment processing; Shared Payment Token storage; Certification or formal ACP compliance claim | https://developers.openai.com/commerce/guides/get-started |
| Universal Commerce Protocol | Gives clients and platforms a structured way to expose commerce capabilities instead of relying on scraped pages. | Client profile and capabilities; Offer, catalog, checkout, fulfillment, policy, and post-purchase data where applicable; Capability extensions and transport bindings such as REST, MCP, or A2A | Akii prepares UCP-style client profiles and readiness evidence. | partial | /docs/protocols/ucp | Google UCP certification; Native checkout execution; Payment-handler operation | https://ucp.dev/ |
| Model Context Protocol | Lets AI clients query approved client data through a stable tool contract instead of scraping arbitrary pages. | Tool names and schemas; Structured tool responses; Approved client, offer, location, policy, source, and action data | Akii exposes approved Commerce Graph data through read-only MCP-compatible tools. | supported | /docs/protocols/mcp | Transactional MCP tools; Unapproved private graph data exposure; Arbitrary tool execution | https://modelcontextprotocol.io/specification/2025-11-25 |
| Agent2Agent Protocol | Allows another system to understand what a client-facing agent can read or hand off safely. | Agent Card metadata; Capabilities and supported operations; Public output URL and safety limits; Structured client and action-path payloads | Akii exposes A2A-style discovery and safe client read/handoff capabilities. | partial | /docs/protocols/a2a | Autonomous transaction execution; Unauthorized booking or lead submission; Official certification claim | https://a2a-protocol.org/latest/ |
| Agent Payments Protocol | Clarifies how intent, authorization, payment credentials, and seller accountability should be handled when agents are involved. | Seller identity; Checkout and payment-handoff readiness; Refund, cancellation, deposit, fulfillment, and support policies; Evidence that payment execution is handled by an approved provider | Akii prepares client-side payment-handoff readiness for AP2-style flows. | readiness | /docs/protocols/ap2 | Payment mandate issuance; Payment token handling; Card data storage; Payment execution | https://ap2-protocol.org/ |
| AG-UI | Gives UI surfaces a predictable way to render agent output and state updates. | Structured offer, service, package, and action payloads; Safe UI state and handoff targets; Declarative payloads that avoid arbitrary code execution | Akii can export structured Agent UI payloads for approved commerce actions. | export | /docs/protocols/ag-ui-a2ui | Arbitrary runtime UI code generation; Guaranteed renderer compatibility across every AG-UI client | https://docs.ag-ui.com/introduction |
| A2UI | Lets agents describe useful UI cards and forms while keeping renderer control with the client application. | Declarative card and form payloads; Commerce entity fields; Approved handoff and action target metadata | Akii can emit declarative A2UI-style commerce payloads for approved data. | export | /docs/protocols/ag-ui-a2ui | A formal A2UI certification claim; Client-side renderer shipping as part of public docs | https://a2ui.org/introduction/what-is-a2ui/ |
| Schema.org and Google structured data | Helps crawlers and search systems parse business, product, offer, and organization information from rendered web pages. | Organization, LocalBusiness, Product, Offer, Service, Store, and policy fields; JSON-LD output that matches visible page content; Accurate pricing, availability, review, return, and seller information where used | Akii can publish JSON-LD-style structured outputs from approved client data. | supported | /docs/schemas | Guaranteed rich result eligibility; Manual-action immunity; Search ranking guarantees | https://schema.org/ |