From product knowledge to reliable page action: introducing SKU.md WebMCP Readiness

A shopper asks an agent to find a carry-on suitcase that fits an airline’s size limit, compare two shell materials, and show the right color on the merchant’s product page. This is one shopping task, but it crosses two different moments. Before an agent visits the store, it needs dependable product knowledge: identifiers, dimensions, material claims, compatible options, and the evidence behind them. After the page opens, it needs a reliable way to act in the visible interface: select the color, expose the matching configuration, or navigate to the relevant part of the page.

Those moments should not be collapsed into one promise. SKU.md lets an agent understand a product before an agent visits. WebMCP lets an agent act reliably after it reaches the merchant page, in the visible interface the user can inspect. Live systems remain the authority for final commercial facts such as current price, inventory, delivery, tax, payment, and order state. SKU.md WebMCP Readiness is the workbench that helps merchants test that handoff without pretending that a static clue is runtime proof.

Three layers, three kinds of authority

Each layer should answer only the questions it can prove. Durable knowledge must not overrule the running page or the systems that settle a transaction.

Layer	What it is authoritative for	What it must not claim
SKU.md product knowledge	Merchant-reviewed facts, identifiers, claims, disclosures, compatibility, source material, scope, and review time before a visit.	That a page tool is registered now, or that a changing commercial value is current.
WebMCP and the visible UI	Tools registered by the page in its current browser context, plus a user-visible response to a narrow page action.	A price, inventory position, permission, or transaction state that the page did not verify.
Live Catalog, backend, and Checkout	Current price, inventory, delivery eligibility, tax inputs, payment authorization, order state, and final confirmation.	That a static document or an earlier page observation is still current.

This division is the product narrative in operational form: SKU.md gives the agent evidence before the visit; WebMCP connects intent to a visible page action after arrival; live commerce systems decide the final commercial facts. None replaces the others.

A Bridge clue is not a working tool

A page source can contain a declarative marker, a call to a WebMCP API, or a Cloudflare Bridge path. Those are useful discovery signals, but they only show that the page contains a clue. They do not prove that the relevant browser recognized the interface, that a tool was registered in the current page state, that its input Schema is valid, or that a call can succeed.

Runtime state changes. A tool may appear after a component mounts, disappear when a selection becomes invalid, or depend on a browser experiment unavailable elsewhere. A Bridge may deliberately do nothing in an unsupported browser. Descriptions and merchant-authored text can also contain misleading or prompt-injection-like instructions. Readiness therefore records discovery, registration, calling, visible response, safety review, and environment verification separately.

Static preflight never executes the target page’s JavaScript and never calls a target MCP endpoint. Its strongest honest conclusion is that it found a signal. Runtime evidence must come from the target page inside a real browser context.

The five-step merchant workflow

The workbench keeps the test narrow enough that a merchant can understand and repeat it.

1. Enter one exact page. Choose a public HTTPS product, cart, checkout, or order URL. Optionally ask the preflight to compare the same-origin root product document, while keeping the page and document as separate resources.
2. Run static preflight. SKU.md checks the response contract, looks for WebMCP-related source signals, records explicit security blockers, and compares the optional product document’s page scope. It does not execute the page.
3. Discover tools locally. Open the exact target page, review the generated discovery runner, and run it in that page’s browser context. The resulting receipt records the named interface, browser context, URL, time, and sanitized tool inventory. Discovery alone still does not prove execution.
4. Call one read-only tool. Only a tool explicitly marked readOnlyHint: true can be selected. Use the smallest useful input after confirming that the page is public, unauthenticated, and free of the listed safety blockers. Raw parameters and output remain temporary in that page.
5. Confirm and export. Record whether the visible page state changed when a change was expected, then import the sanitized receipt. Download a local JSON or Markdown report and, only when every gate passes, a WebMCP capability candidate for human review.

One call establishes evidence for a specific page and environment; it does not operate a storefront or exercise transaction flows.

Read the six evidence levels separately

The report preserves six levels because each answers a different question:

• Page signal discovered: did static HTML contain a relevant WebMCP or Bridge clue?
• Tool registered: did a recognized browser interface return at least one tool with a valid Schema?
• Read-only call succeeded: did the selected tool carry the read-only annotation and complete one minimal invocation?
• Visible UI synchronized: when the tool was expected to change the page, did the merchant confirm a visible URL, filter, option, or state change?
• Safety review completed: did the merchant confirm the public, logged-out context and review origin, untrusted content, and prompt-injection concerns?
• Named runtime verified: does the receipt identify the tested interface, browser, exact page, security context, and check time?

Each level receives one of four evidence states:

• passed means the required evidence for that level was collected and met the rule.
• failed means the check produced evidence of a definite violation or unsuccessful result.
• incomplete means evidence is absent, stale, unsupported, or insufficient; it is not automatically a product failure.
• not_applicable is used only when a level genuinely does not apply, such as visible synchronization for a pure query that should not change the page.

The overall result uses only passed, failed, or incomplete. A static page with a promising Bridge clue normally remains incomplete until runtime evidence exists. That conservatism is the point: the report should describe what was proved, not reward an optimistic interpretation.

What the merchant learns from the report

The first page of the report answers practical questions rather than presenting a generic score:

• How many tools could the named runtime discover on this exact page?
• Which tools have a valid input Schema and an explicit read-only annotation?
• Which issue is currently blocking safe agent use, and what can the merchant change?
• Did the page actually respond to the one selected call, and was an expected visible state synchronized?
• Does the optional SKU.md declaration cover this exact page without claiming live authority?
• Has the evidence crossed every gate required to generate a beta capability candidate?

The report records the target, scope, adapter, browser context, and time. A receipt older than 24 hours, or with a mismatched URL or scope, cannot produce a candidate.

The machine-readable shape is documented in the neutral SKU.md WebMCP Readiness v1 Schema. It is a tool-report contract, not part of the SKU.md v0.10 product-document Schema and not a WebMCP standard.

Local privacy and a deliberately small safety boundary

The exact page URL and optional same-origin product-document URL go to SKU.md’s preflight endpoint for a limited public read. The request carries no merchant-page cookies; preflight runs no target JavaScript or tools.

Runtime discovery and the selected tool call happen in the merchant’s browser on the target page. Raw tool parameters, raw tool output, cookies, tokens, and complete user conversations are not sent to SKU.md and are not included in the export. The report keeps only sanitized metadata such as tool name, result status, hashes, byte counts, duration, and before-and-after page state.

The first release is limited to a publicly accessible, logged-out page and one clearly read-only tool. It does not test member pricing, personal data, authenticated orders, payment, returns, checkout completion, or any operation that changes commercial state. Tool descriptions, input Schemas, output summaries, merchant copy, and third-party content are treated as untrusted text; a declaration is not permission to execute it.

A beta candidate is review material, not authority

When preflight, a recognized runtime, registration, a valid Schema, the merchant’s public-session confirmation, one read-only call, and all safety checks pass within the time window, the workbench can produce a beta capability candidate. The candidate uses one exact page pattern and states that a browser page runtime and user presence are required.

The file does not copy the dynamic inventory, create a wildcard, grant permission, publish itself, upgrade Basic to Commerce, or authorize a transaction. A merchant reviews and merges it by hand. Existing Commerce declarations receive a diff; Basic documents receive a list of remaining Commerce requirements.

Readiness is therefore not the production Bridge promised by a static signal. It is the evidence process that should precede any Bridge decision. Production packs, write actions, checkout, orders, and backend MCP connections need separate design and security review.

Start with one real product page

Choose a stable, public product page that directly returns HTML, run the static check, and stop if the result is only a clue. Continue with local runtime discovery only in the exact page you control, then test one unmistakably read-only tool. An honest incomplete report is more useful than a passed badge assembled from assumptions.

Open the localized WebMCP Readiness workbench to test a page. For the underlying separation between product knowledge and browser page actions, read SKU.md v0.10 × WebMCP: product knowledge before the visit, structured action on the page.

Further reading

Place page actions in the wider runtime chain with AI commerce authority handoffs.