The missing publisher-side WebMCP layer.
The W3C WebMCP draft specifies the browser API. cf-webmcp is the piece that lets a non-technical publisher add tools to an existing site without touching their CMS or installing an SDK.
What it is
A single Cloudflare Worker per customer, configured by one TOML file. Three production templates ship: default, wordpress, woocommerce (Store API).
What it is not
- Not a hosted SaaS.
- Not a crawler. The publisher writes the TOML; the Worker does not infer tools.
- Not Anthropic's MCP. WebMCP is a browser API (
document.modelContext, formerlynavigator.modelContext); MCP is a JSON-RPC protocol. They are different specs. Desktop MCP clients bridge into a WebMCP site via the fallback widget. - Not affiliated with Cloudflare. The
cf-prefix only reflects that the project runs on Cloudflare primitives.
Why now
Chrome 149 and later turn on the WebMCP runtime (document.modelContext; in Chrome 149 the deprecated navigator.modelContext) for sites that send an origin-trial token; without one it is behind a flag. Cloudflare's Kitesurf agent browser supports it, and in Browser Run lab sessions an agent lists and calls a page's tools over the DevTools protocol. Discovery conventions (/.well-known/webmcp, <link rel="webmcp">) are converging. The producer-side equivalent - the thing that gets tools onto a site - is not specified anywhere. cf-webmcp fills that gap.
Acknowledgements
- Suganthan Mohanadasan, "WebMCP: I Made My Website AI Agent Ready" - the implementation guide that informed the publisher-side discovery patterns.
- jasonjmcghee/WebMCP - the fallback widget that bridges desktop MCP clients.
- webmachinelearning/webmcp - the W3C draft.
License
MIT. Source on GitHub.