Skip to content

Supported agent protocols

This page lists the agent protocols and discovery formats Sill speaks, and how far each one goes today. The status table is generated from the same list the dashboard shows under Settings → Install → Endpoint → Protocol support, so the two always agree.

Each protocol has one of five statuses:

StatusMeaning
LIVEAvailable now. A note after the word gives any limit, for example “agent card only”.
BUILT · NOT ENABLEDBuilt, but not available to merchants.
ROADMAPPlanned.
DEFERREDNot planned for now.
NOT STARTEDNot begun.
ProtocolKindStatusScope todayVersion as declaredSpec
MCP — Model Context Protocol (Anthropic)mandate protocolLIVEPer-site MCP server: initialize, tools/list and audited tools/call over Streamable HTTP. Skills are the tools.2025-06-18modelcontextprotocol.io
A2A — Agent-to-Agent (Google)mandate protocolLIVE · agent card onlyA signed, A2A-shaped agent card per verified site. A2A task methods (message/send) are not implemented — agents call skills over MCP.a2a/1.2a2a-protocol.org
AP2 — Agent Payments Protocol (Google)mandate protocolLIVE · boundarySigned AP2 mandates are admitted; cart total and currency feed the policy engine and settle on your connected rail. Inside UCP checkout, AP2 runs as the mandates extension: every cart Sill prices is signed on your behalf, and a shopper-approved mandate is checked against those signed terms before anything is charged.—ap2-protocol.org
ARD — Agentic Resource Discovery (ARD)discovery surfaceLIVEA signed ai-catalog.json per site (did:web identity, detached ed25519 JWS), served at the edge.1.0—
llms.txt — llms.txt (llmstxt.org)discovery surfaceLIVEA live llms.txt per site, generated from your skills and endpoints.—llmstxt.org
HTML gateway — HTML agent gateway (/agent) (Sill)discovery surfaceLIVEAn HTML page for runtimes that read pages rather than JSON, linking your card and MCP server.——
JWKS — Public signing keys (RFC 7517)discovery surfaceLIVEPublic keys at edge.sill.so/.well-known/jwks.json so anyone can verify Sill signatures.—www.rfc-editor.org/rfc/rfc7517
ACP — Agentic Commerce Protocol (Stripe (with OpenAI))mandate protocolBUILT · NOT ENABLEDShared Payment Token checkout is built but not available to merchants yet. The discovery half of ACP is served today via your catalog and agent card.2026-04-17docs.stripe.com/agentic-commerce
UCP — Universal Commerce Protocol (Google × Shopify)merchant endpointLIVE · checkout + orders, Stripe railOpen checkout spec from Google and Shopify. Sill is your store’s UCP endpoint: it publishes your profile at /.well-known/ucp and runs signed checkouts — cart priced from your catalog and signed on your behalf (AP2 mandates extension), your guardrails, human review when a rule asks, your shipping options and tax rules, payment through Google Pay to your Stripe account, a signed record of each decision — and it reports the order back (refunds, disputes) through signed webhooks. Checkout is advertised once Stripe is connected with its rail on, the site settles through Stripe, a policy is published, and (with a live Stripe account) a Google Pay merchant ID is set. Being listed on Google’s shopping surfaces requires Google’s merchant approval.2026-08-25ucp.dev
Web Bot Auth — Signed agent requests (RFC 9421) (IETF)identityLIVE · Worker and plugin installsChecks the signature some agents attach to their requests against the signer’s published key, so a visit is a verified identity rather than a user-agent guess. Agents that sign today include ChatGPT agent mode and Exa.draft-ietf-webbotauth-httpsig-protocol-00datatracker.ietf.org/wg/webbotauth/
x402 — x402 (Coinbase · Stripe)mandate protocolDEFERREDOn-chain HTTP-native payments. No code, no timeline.—x402.org

A mandate is the signed request an agent sends to act on your store (see Signed mandates). Its protocol_context.protocol field must be one of three values: a2a, ap2 or mcp. A mandate with any other value is rejected before your policy runs, and the agent receives outcome: rejected with reason identity_check_failed (HTTP 401). The specific reason, protocol_unsupported, is recorded in your audit log.

Discovery formats (ARD, llms.txt, the /agent page, the JWKS) are files Sill serves. They never appear on a mandate.

flowchart LR
  A[Agent sends a signed mandate] --> B{Protocol is a2a, ap2 or mcp?}
  B -->|yes| C[Check signature and agent identity]
  B -->|no| D[Rejected]
  C --> E[Evaluate your policy]
  E --> F[Approve, escalate or reject]
  D --> G[Signed audit record]
  F --> G

Sill runs an MCP server for each verified site:

POST https://edge.sill.so/v1/mcp/{site_key}

It supports initialize, tools/list and tools/call over Streamable HTTP. The tools are your site’s skills — the same set your agent card lists. Every tools/call is recorded in your signed audit log. Skills connected to your store or your own endpoint return live data; actions that move money (for example place_order) need a signed mandate and go through your policy like any other mandate.

MCP responses are not signed. The agent card that points to your MCP server is.

See MCP server and Discovery skills.

Sill publishes a signed, A2A-compatible agent card for each verified site:

GET https://edge.sill.so/v1/agent-card/{site_key}.json

The card uses protocol_version: "a2a/1.2" and lists only the skills your site actually offers. Anyone can verify it against Sill’s public JWKS. A2A task methods such as message/send are not supported; agents call your skills over MCP. Agents can sign mandates with protocol_context.protocol: "a2a".

See Agent card and Verify a signature.

Sill accepts mandates with protocol_context.protocol: "ap2". The AP2 cart fields cart_total and cart_currency are checked for shape and evaluated by your policy’s cart and currency rules, and approved orders settle on your connected rail (Stripe, or Shopify in test mode). Sill does not validate the full AP2 IntentMandate, CartMandate or PaymentMandate objects.

Inside UCP checkout, every checkout response carries your terms signed by Sill, and a shopper-approved AP2 checkout mandate is checked against those terms before any payment.

See Signed mandates and Policy engine.

Sill publishes a signed ai-catalog.json for each site:

GET https://edge.sill.so/v1/catalog/{site_key}.json

The catalog is specVersion 1.0, with host.identifier set to did:web:{domain} (did:web). Each trustManifest carries a detached ed25519 JWS over the RFC 8785-canonical manifest, verifiable against the public JWKS.

The signature covers the trust manifest (who publishes the catalog). Each entry’s url, capabilities and description are outside the signature and rely on did:web and TLS, as the ARD specification defines. To trust the agent card or MCP server an entry points to, verify that surface on its own.

See ARD catalog.

Sill acts as your store’s UCP endpoint. It publishes your business profile at /.well-known/ucp (on Cloudflare Worker and WordPress plugin installs), runs checkouts priced from your catalog under your guardrails, sends orders to human review when a rule asks, takes payment through Google Pay into your connected Stripe account, records each decision in the signed audit log, and reports order updates back to the platform through signed webhooks.

Checkout is advertised once Stripe is connected, the rail is turned on, the site settles through Stripe and a policy is published; with a live Stripe account it also needs a Google Pay merchant ID. Being listed on Google’s shopping surfaces requires Google’s approval of your store. See UCP checkout.

On Cloudflare Worker and WordPress plugin installs, Sill checks the signature some agents attach to their requests (RFC 9421) against the signer’s published keys. A valid signature shows the visit as VERIFIED · SIGNED instead of relying on the user agent. ChatGPT agent mode, ExaSearchBot and others sign their requests; the plain ChatGPT-User and Claude-User fetchers do not. A failed signature is shown on that visit and does not block the agent on its own.

ACP is Stripe’s format for agentic checkout. The discovery half — a structured feed agents can read — is served today through your signed catalog and agent card.

For checkout, Sill works alongside Stripe: before Stripe charges an agent checkout, it asks Sill’s order-approval endpoint whether your policy allows the order, and Sill records a signed trail afterwards. Stripe issues and redeems the Shared Payment Token; Sill never holds it. The order-approval endpoint runs for a small number of merchants while Stripe’s agentic commerce program is limited, and is not self-serve. Mandates with protocol: "acp" are not accepted. See Agentic checkout (Stripe ACP).

Not supported, and not planned for now. Mandates with protocol: "x402" are not accepted.

a2a, ap2 and mcp.

What does an agent see if it uses another protocol value?

Section titled “What does an agent see if it uses another protocol value?”

outcome: rejected, reason identity_check_failed, HTTP 401. Your audit log records the specific reason, protocol_unsupported, so you can see what happened.

A2A is the protocol. The agent card is the signed JSON file that describes your site in the A2A format. It lives at https://edge.sill.so/v1/agent-card/{site_key}.json and can be verified against the public JWKS with standard tools.

No. The agent card that points to your MCP server is signed. Orders placed through tools/call (for example place_order) carry a signed mandate, which is verified the same way as one sent to the mandate endpoint.