SKU.md v0.10 × WebMCP: product knowledge before the visit, structured action on the page

A shopper asks an agent for a quiet air purifier that is suitable for a nursery, has a replaceable filter, and will fit a particular room. Before the agent opens a shop, it needs a dependable way to distinguish product facts from slogans: which model and Variant match, what the noise measurement means, what evidence supports the claim, and which limitation belongs in the answer. Once the product page is open, the task changes. The shopper may want to select a filter size, compare the visible specifications, or ask the page to add that identified Variant to a cart. The first problem is durable product understanding; the second is safe interaction with the current page.

SKU.md v0.10 and WebMCP meet at that handoff, without becoming the same thing. SKU.md is a merchant-published product knowledge and evidence layer. WebMCP is a browser page API that makes actions available from the page that is already in front of the user. A good agent uses the first to form an evidence-backed intent, then the second to carry out a narrow, visible page action, and finally returns to live commerce systems for any decision whose value can change.

A purchase starts before a tab exists

The initial question is rarely “which button should I press?” A shopper might ask whether a product is compatible with a device they already own, whether a material claim is backed by a named test, or whether a child-safety warning applies to a particular configuration. Those questions should be answerable before a tab exists, and the answer should retain its source, scope, and review date. An old price tile or a stale availability phrase must not quietly acquire the authority of a current quote just because it appeared alongside an otherwise useful product explanation.

That is the job of SKU.md v0.10. It can attach stable Product, Variant, SKU, and GTIN identifiers to merchant-reviewed facts, claims, disclosures, compatibility guidance, source material, and verification times. The file is useful when an agent is planning a visit, comparing products across a buyer’s stated needs, preparing an explanation with citations, or checking that it has the precise model in mind. It is not an executable session, a live inventory response, or an instruction to purchase.

WebMCP begins later. Chrome’s WebMCP overview states the practical limitation plainly: a browser page context is required, and a page must already be open inside it. A local or remote browser session can provide that context. WebMCP is not a backend API, offline call, or pre-visit discovery mechanism. WebMCP does not provide backend MCP transport, a static tool inventory, or cross-site discovery. It lets an active page expose actions that are meaningful in that page’s current UI state.

This distinction prevents a tempting but unsafe shortcut. An agent cannot read a SKU.md capability declaration, invent a tool call, and operate a merchant site that the user has not opened. Nor should a merchant publish today’s button names and output schemas into a durable product document. A user can change locale, sign in, choose a Variant, empty a cart, or lose permission between the time a document is read and the time a page is visited. The running page, not the document, knows which actions exist now.

What WebMCP exposes, and what it does not

The WebMCP Community Group draft defines JavaScript-based tools supplied by web applications to agents. The Imperative API registers a tool with document.modelContext.registerTool(): the page supplies a name, description, input schema, execution callback, and optional annotations. This is appropriate when the action needs application logic, state checks, navigation, or a carefully structured result.

The Declarative API instead enhances an ordinary HTML form. The toolname attribute names the action and tooldescription describes its purpose. When an agent invokes it, the browser focuses the visible form and fills its fields; the user can see what will happen. Removing either attribute unregisters the tool. This is useful for a bounded request such as asking for product support or requesting a restaurant reservation, not for pretending that an autonomous browser can complete every commercial commitment without review.

Chrome’s DevTools for agents is related only as a debugging surface. Its configuration documentation describes an MCP server that connects an agent to Chrome for inspection and testing. It is a separate MCP debugging bridge, not the merchant’s WebMCP tool endpoint and not an alternative product-discovery protocol. It can help a team inspect registrations, invoke a development tool, and review structured output; it does not turn page tools into a backend or offline commerce API.

The official demonstrations make the boundary concrete. The Smart Home demo registers a rearrangeDOMComponents tool that changes which simulated dashboard components are visible; it does not control real devices. The French Bistro demo shows a declarative, visible reservation-request form with details such as date, time, party size, seating preference, and special requests, and its demo page uses a polyfill when native support is unavailable. They demonstrate that tools can map complicated page interaction to structured intent. They do not demonstrate universal discovery, cross-site execution, reliable fulfillment, payment authorization, or a completed commercial transaction. Demonstrations are not real transactions.

A clean responsibility matrix

The following separation is deliberate. It avoids making one convenient layer answer questions for which another layer is authoritative.

Surface	Authoritative responsibility	What an agent should do
SKU.md	Knowledge evidence: reviewed facts, claims, disclosures, compatibility, provenance, and stable identifiers.	Explain and cite; identify the exact Product, Variant, SKU, and GTIN.
WebMCP and visible UI	Current page tools and user-visible interaction state.	Discover the registered tool after opening the page, then make a bounded page action.
Live Catalog and merchant backend	Current price, inventory, eligibility, delivery choices, tax inputs, and account-specific rules.	Re-query rather than trust a static snapshot.
Checkout	Final price, delivery, tax, payment authorization, consent, and purchase confirmation.	Present the final state and preserve the confirmation boundary.

A useful source-backed sentence in SKU.md can describe a manufacturer’s list price as a historical or reviewed fact, but it does not become a current price. The same is true for availability, promised delivery windows, promotions, and taxes. They may be helpful context, but they are live commercial facts only when returned by the current Catalog, backend, or Checkout path.

What v0.10 actually declares

SKU.md v0.10 already has a narrow way to advertise that a visit may unlock a page capability. A capabilities[] entry can use protocol: webmcp, identify page_runtime, limit the feature with scopes and page_url_patterns, and require requires_user_presence: true. This is an access hint: it tells a consumer that the merchant may expose a relevant page-runtime capability after the user opens a matching URL.

It is intentionally not a copy of the dynamic interface. Tool names, input and output schemas, tool descriptions, and registered state belong to the active page runtime and are not copied into SKU.md. The v0.10 JSON Schema defines the machine-readable document boundary; the English v0.10 specification remains the only normative text. Runtime details stay outside SKU.md, so a stale document cannot masquerade as a current tool contract. A consumer should treat page_url_patterns as a navigation hint, not permission to call an unpublished operation or a promise that every listed page currently registers a tool.

That division is practical as well as principled. A product page may register one read-only comparison tool before a Variant is chosen, swap it for a configuration tool when selections are valid, and unregister an action after a cart state changes. Its current tool set can reflect login, locale, inventory, accessibility, and consent. A static document cannot do that safely.

The complete agent path

An agent can follow this sequence without inventing authority:

1. Read SKU.md and its evidence, disclosures, and scope.
2. Resolve the exact Product, Variant, SKU, and GTIN; if identity is ambiguous, ask rather than guessing.
3. Open the merchant page that matches the safe page URL pattern, with the user present.
4. Discover the tools the active page actually registers.
5. Choose one tool whose description matches the requested page action, then execute it in the visible UI.
6. Return to the live Catalog or merchant backend for current commercial state.
7. Use Checkout for final totals, taxes, delivery, payment authorization, and a final user confirmation.

The steps are intentionally not a single “buy” tool. A tool can select a known Variant, explain a currently visible comparison, start a reservation request, or open a cart view. Final purchase needs a fresh quote and a confirmation that is meaningful at the moment of commitment. We do not recommend toolautosubmit for final purchase. A form may support automatic submission in the Declarative API, but its availability is a browser behavior, not evidence that a merchant should skip server-side checks or the shopper’s final decision.

Merchant practices that survive the boundary

Publish human-reviewed product facts and evidence. Stable identifiers matter because a good explanation cannot be safely applied to a nearby model or an arbitrary color/size variant. Include the source and limits of each material claim; retain disclosures rather than asking an agent to infer them from sales copy. Review and update a document when the fact itself changes, while leaving real-time states to the systems that own them.

Keep each page tool to one responsibility. “Select this identified Variant” and “show the compatibility explanation” are understandable. “Find, configure, discount, pay, and order” hides too many commitments in one call. Register a tool only while its user-visible state makes it valid, and unregister it as state changes. Tool metadata is also untrusted input: concise, accurate descriptions and schemas reduce ambiguity, but they do not erase prompt injection or implementation risk.

Treat readOnlyHint and untrustedContentHint as hints, not security guarantees. A read-only label does not prove an implementation makes no change; an untrusted-content marker does not sanitize its output. Keep server-side validation, authorization, idempotency handling, fraud controls, audit logs, and explicit high-risk confirmation. The page should describe effects honestly, and the backend must independently enforce the business rule.

Evaluate the complement, not a ranking claim

The valuable comparison is WebMCP-only versus WebMCP+SKU.md under the same, bounded shopping scenarios. Measure whether the agent matches the requested product and Variant, cites the correct source, discloses limitations and evidence, chooses the appropriate current page tool, rejects an expired quote, and preserves the confirmation boundary. These are observable outcomes that can be checked with fixtures, controlled pages, and recorded human review.

Do not turn that evaluation into a ranking, conversion-rate, or adoption claim. WebMCP can make an already-open interface easier to operate. SKU.md can make pre-visit product understanding more durable and auditable. Neither one alone guarantees a purchase, and together they do not replace a live Catalog, a merchant backend, or Checkout. The practical promise is narrower and stronger: know what product the shopper means before the visit, then act on what the shopper can see after the page is open.

For implementation availability and enrollment details, consult Chrome’s WebMCP Origin Trial at the time of deployment; trial ranges and browser behavior can change.

Further reading

Connect page tools to live and transactional sources in AI commerce authority handoffs.