Bonus agent signals: WebMCP, A2A, AI Catalog, API catalog, rel=ucp

How do bonus checks affect the agent-readiness score?

Bonus checks cover agent-discovery standards that are new, experimental or rarely used on storefronts. Each has weight 1 (low) in the agentic commerce category and follows one rule: it only counts when it’s found.

• Pass: adds a full-credit, weight-1 result to the category.
• Fail: excluded from scoring. Your score is the same as if the check didn’t exist.
• Partial (only the legacy A2A path): counts at half credit.

The scoring rationale is in the scoring methodology. Core agentic commerce checks such as the UCP profile matter far more.

WebMCP tools for in-browser agents

WebMCP is a W3C Community Group draft that lets a page expose actions (search, add to cart) as tools that an in-browser AI agent can call directly instead of clicking through the UI. It is experimental: Chrome 149 origin trial only (Chrome docs).

What the scanner checks on the homepage and sampled product pages:

• a <form toolname="..."> element (declarative API), or
• inline script matching modelContext … registerTool or the string webmcp, or
• a <script src> URL containing webmcp, or
• a Permissions-Policy response header that mentions tools.

External script contents aren’t fetched, and tools registered at runtime by bundled JavaScript can be missed. Pass if any signal is found; otherwise the check doesn’t count.

How to add it:

<form action="/search" method="get" toolname="search_products" tooldescription="Search the product catalog by keyword">
  <input name="q" type="search" />
</form>

document.modelContext?.registerTool({
  name: 'add_to_cart',
  description: 'Add a product variant to the cart',
  inputSchema: {
    type: 'object',
    properties: { variantId: { type: 'string' }, quantity: { type: 'integer' } },
    required: ['variantId'],
  },
  async execute({ variantId, quantity = 1 }) {
    return addToCart(variantId, quantity);
  },
});

The API is moving from navigator.modelContext to document.modelContext. Check the draft before shipping.

A2A agent card

A2A (Agent2Agent) is a protocol for agents to delegate tasks to other agents. A server describes itself in an agent card: name, endpoint, skills and auth. UCP can use A2A as a transport, but no major store probed on 2026-10-14 served an agent card.

What the scanner checks:

• GET /.well-known/agent-card.json returns JSON with a name → pass.
• Only the legacy /.well-known/agent.json (pre-v0.3) path returns JSON with name → partial.
• Neither → not counted.

How to add it: serve a static JSON card. Fields below are a minimal sketch; follow the A2A specification for the full schema.

{
  "name": "Example Store shopping agent",
  "description": "Search products, build carts and check order status.",
  "url": "https://store.example/a2a",
  "version": "1.0.0",
  "skills": [{ "id": "product-search", "name": "Product search", "description": "Find products by keyword" }]
}

AI Catalog (MCP server cards)

The AI Catalog is a Linux Foundation-hosted, cross-protocol index at /.well-known/ai-catalog.json. It is the domain-level discovery mechanism chosen by MCP’s SEP-2127 Server Cards (Final, optional). It lists or embeds the store’s MCP server cards. Earlier drafts used /.well-known/mcp or /.well-known/mcp/server-card.json; those paths are superseded and not checked.

What the scanner checks: GET /.well-known/ai-catalog.json returns a JSON object → pass. The scanner doesn’t validate the catalog schema. Adoption is near zero: none of the 10 major retailers probed served one.

How to add it: publish /.well-known/ai-catalog.json with Content-Type: application/json, listing your MCP server card in the format defined in the AI Catalog repository. Each MCP server also serves its own card at <mcp-url>/server-card (application/mcp-server-card+json). Server cards don’t include tools, so clients still call tools/list, which is why a working agent endpoint matters more.

API catalog (RFC 9727)

RFC 9727 defines /.well-known/api-catalog, a standard place to list a site’s public APIs and their OpenAPI descriptions. It is most useful for headless stores whose storefront API is public.

What the scanner checks:

• the homepage Link header contains rel="api-catalog" or rel="service-desc" → pass, or
• GET /.well-known/api-catalog returns JSON with a linkset key → pass.

How to add it:

GET /.well-known/api-catalog
Content-Type: application/linkset+json; profile="https://www.rfc-editor.org/info/rfc9727"

{
  "linkset": [
    {
      "anchor": "https://store.example/store",
      "service-desc": [{ "href": "https://store.example/openapi.json", "type": "application/vnd.oai.openapi+json" }],
      "service-doc": [{ "href": "https://store.example/docs/api", "type": "text/html" }]
    }
  ]
}

And on the homepage: Link: </.well-known/api-catalog>; rel="api-catalog".

Medusa’s Store API reference is generated from OpenAPI specs, but exposing an OpenAPI description through api-catalog on your store domain is something you add yourself.

UCP profile advertised with rel="ucp"

A rel="ucp" link points agents from any page to your UCP profile. It isn’t in the UCP spec text. Some hosted storefronts already serve it as both a header and an HTML tag.

What the scanner checks: the homepage Link response header contains rel="ucp", or the HTML has <link rel="ucp"> → pass.

How to add it:

Link: </.well-known/ucp>; rel="ucp"

<link rel="ucp" href="/.well-known/ucp" />

How to fix it on Medusa

None of the five signals is built into Medusa. All can be added:

• WebMCP and rel="ucp": in the storefront, as form attributes, a script and a <link> tag or response header.
• Agent card, AI Catalog and API catalog: as static files or custom API routes.

See the Medusa agent-readiness guide.

Sources

• WebMCP draft · Chrome WebMCP docs
• A2A specification · A2A v0.3
• SEP-2127 MCP Server Cards · AI Catalog
• RFC 9727: api-catalog
• UCP specification overview