The README lists "Enable/influence discoverability of sites to agents" as a non-goal, and issue #131 addressed local auto-registration rather than cross-origin pre-flight discoverability. In the meantime, production deployments building for agentic-commerce workloads — especially transact-class tools — are hitting a concrete operational gap: agents can't plan before loading the page, and there's no cryptographic way to verify that a registered tool came from the domain operator rather than a third-party script (tag manager compromise, supply-chain injection).
We've published a forward-compatible profile and a live signed reference implementation that may be useful input if / when the CG decides to revisit this as a goal:
Design choices aimed at round-tripping cleanly into whatever the CG eventually adopts:
| Concern |
Approach |
| Location |
/.well-known/webmcp.json + <link rel="webmcp-manifest"> fallback |
| Integrity |
JCS (RFC 8785) canonical body, Ed25519 signature with signature removed from payload |
| Key reuse |
Same key chain as Web Bot Auth (RFC 9421 / IETF HTTP Message Signatures) and JWK Thumbprint (RFC 7638) — origins signing for WebMCP don't need a new key |
| Risk taxonomy |
riskClass: read / mutate / transact / escalate — maps onto where agent.requestUserInteraction() should gate |
| Drift |
Runtime tool inventory from provideContext() / registerTool() reconciled against manifest; mismatch on transact / escalate halves trust weight |
| Forward compat |
Field names + JSON shapes chosen so a v1.1 alignment to CG-adopted discoverability is losslessly migratable |
Happy to contribute normative spec text or implementation reports if any of this maps to where the CG is heading. Either way, the reference is available to point at from discoverability-adjacent threads (#51, #88, #105) so there's a concrete working example on the table.
—
Disclosure: I'm shipping this through https://getspeakable.ai — a certification platform scoring businesses for AI commerce readiness. The manifest is open-spec; anyone can implement and verify without us.
The README lists "Enable/influence discoverability of sites to agents" as a non-goal, and issue #131 addressed local auto-registration rather than cross-origin pre-flight discoverability. In the meantime, production deployments building for agentic-commerce workloads — especially transact-class tools — are hitting a concrete operational gap: agents can't plan before loading the page, and there's no cryptographic way to verify that a registered tool came from the domain operator rather than a third-party script (tag manager compromise, supply-chain injection).
We've published a forward-compatible profile and a live signed reference implementation that may be useful input if / when the CG decides to revisit this as a goal:
Design choices aimed at round-tripping cleanly into whatever the CG eventually adopts:
/.well-known/webmcp.json+<link rel="webmcp-manifest">fallbacksignatureremoved from payloadriskClass:read/mutate/transact/escalate— maps onto whereagent.requestUserInteraction()should gateprovideContext()/registerTool()reconciled against manifest; mismatch ontransact/escalatehalves trust weightHappy to contribute normative spec text or implementation reports if any of this maps to where the CG is heading. Either way, the reference is available to point at from discoverability-adjacent threads (#51, #88, #105) so there's a concrete working example on the table.
—
Disclosure: I'm shipping this through https://getspeakable.ai — a certification platform scoring businesses for AI commerce readiness. The manifest is open-spec; anyone can implement and verify without us.