Add WebMCP experiment

[gziolo]

The goal is to integrate WebMCP as an experiment in the AI plugin.

Initially explored by @Jameswlepage in:

• Add WebMCP adapter experiment #224

This is where WebMCP actually stands as of early April, as documented in #224 (comment):

Spec: It's a Draft Community Group Report under the W3C Web Machine Learning CG — explicitly not a W3C Standard and not on the Standards Track. Three editors from Microsoft and Google (Brandon Walderman, Khushal Sagar, Dominic Farolino). ~2.2k stars on https://github.com/webmachinelearning/webmcp, latest draft dated March 27.

Things are moving fast and breaking. provideContext()/clearContext() got removed March 5. Standalone unregisterTool() got removed March 27 — now it's registerTool(tool, { signal }) with AbortSignal-based lifetime instead. So if you're reading older blog posts or tutorials, assume half the API surface has changed.

There are two APIs described publicly. The imperative one (navigator.modelContext.registerTool()) takes name, description, optional JSON Schema input, and an async execute(input, client) callback where the client gives you requestUserInteraction() (though its algorithm is still a TODO in the spec). The declarative one proposes HTML form attributes (toolname/tooldescription) plus JS/CSS additions like SubmitEvent.agentInvoked, SubmitEvent.respondWith(), and :tool-form-active/:tool-submit-active pseudo-classes — but the entire declarative section is marked as TODO right now.

Worth emphasizing: WebMCP is MCP-inspired but not MCP. Chrome's guidance says it's "not an extension or a replacement of MCP." The browser mediates everything between the site and its built-in agent — no JSON-RPC.

Some notable open questions: discovery is explicitly a non-goal in the repo README (tools are tab-bound, registered during the user's visit, ephemeral). Multi-agent negotiation (in-page vs. extension vs. in-browser agents) is tracked but unresolved. requestUserInteraction is in the IDL but has no normative algorithm yet. Headless is also a non-goal.

Browsers: Chrome published an early preview announcement Feb 10. There's an early DevTrial targeting desktop milestone 146 — the flag needs Chrome 146.0.7672.0+, reachable via Beta or Canary depending on timing. Important: this is explicitly framed as an early prototype for developer testing, not an intent to ship.

Edge — Microsoft co-authors the spec and Patrick Brosset said "stay tuned for more news from the Edge team," but there's no public ship timeline.

Firefox/Safari — blink-dev lists "Gecko: No signal" and "WebKit: No signal." No webmcp issues in either Mozilla's or WebKit's standards-positions repos.

Polyfill situation: You can experiment across browsers today, but a JS-only polyfill matches the API shape without native browser-agent mediation (trust model, permission UIs, CSS pseudo-classes, SubmitEvent.agentInvoked). The @mcp-b/webmcp-polyfill package gives you registerTool (and recently removed unregisterTool) on navigator.modelContext and keeps provideContext/clearContext as deprecated compat shims — it does not add callTool or listing APIs. @mcp-b/react-webmcp has React hooks with Zod validation. @mcp-b/transports covers postMessage tab/iframe and Chrome extension messaging for MCP connectivity in browser contexts.

So what does this mean for us? If your tool abstraction is name + description + JSON Schema + implementation, it maps cleanly to both WebMCP's ModelContextTool and MCP's tool definitions. The Abilities API fits this shape — it can feed both transports.

[swissspidy]

APIs and standards aside, I highly recommend checking out some demos at https://github.com/GoogleChromeLabs/webmcp-tools/ or videos such as https://www.youtube.com/watch?v=xQAYZBDV5jg to get a better understanding of WebMCP and its goals.

Also worth noting that in WordPress there would be 2 target audiences for this:

1. A logged-in user in wp-admin (e.g., admins, editors, contributors managing the site)
2. A visitor on the website front end (e.g., shopping for products, leaving comments)

[justlevine]

My concern about polyfiling is that both MCP and WebMCP beyond their own unstableness are explorative and moving quickly in different directions.

I think outsourcing the overhead of maintaining the polyfill to a 3rd party is a great idea, and something I think we can feel comfortable doing as a canonical plugin Experiment. the Experiment status would allow us to retire it more easily if contributors are unable to keep up with (the speed of) maintenance or if the spec itself turns out to be bunk.

(At the same time, I would caution us from diverting team resources away from more immediately practical and Experiments or Features to focus on this at their cost.)