Add WebMCP experiment

@Jameswlepage

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.

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:

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

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.)

OpenAI has included support to WebMCP https://openai.com/webmcp-challenge/

@fellyph

Following up on @fellyph's note: ChatGPT's browser shipping WebMCP support (Aug 25) changed the ground truth this issue was parked on in April. i've now run a WordPress WebMCP integration in production against it, built exactly the way the issue body hypothesized: Abilities API as the single tool registry, feeding both MCP and WebMCP. It works, and it surfaced concrete findings that i think are directly useful for designing the experiment.

The current dialect (as implemented by ChatGPT's in-app browser, tested Aug 26-28):

modelContext is exposed on document (not navigator) and is a frozen object implementing only registerTool. Batch provideContext throws, and in non-strict code the polyfill assignment fails silently, so tools just never register. Register one tool at a time.
Agent browsers impose a per-page tool budget. Registering our full catalog (296 tools) disabled WebMCP for the document entirely, with no error. A curated ~30-tool set works. This makes @swissspidy's two-audiences point above load-bearing for the design: the experiment needs per-context (logged-in wp-admin vs. front-end visitor) tool scoping from day one, not as a refinement.

WordPress-specific integration traps any implementation here will hit:

REST cookie auth needs the wp_rest nonce in X-WP-Nonce, and core hard-rejects any other nonce riding in that header. If the bridge uses its own CSRF token, it must travel in a separate header (we use two nonces: X-WP-Nonce for core, a second header for the bridge). Getting this wrong makes logged-in tool discovery run as an anonymous visitor: 401, zero tools, on every default-configured site.
Ability names contain /, and an URL-encoded slash is rejected by stock Apache before WordPress runs (AllowEncodedSlashes Off). Execution 404s on every Apache host. We map / to __ in the execute route; the experiment will need some separator convention too.

These were all found and fixed against the GPL bridge this ecosystem already has (code-atlantic/webmcp-abilities); the fixes are reported at code-atlantic/webmcp-abilities#3 with a standing PR offer, and our patched fork is public at https://github.com/respira-press/webmcp-for-wordpress (GPL-2.0). Live reference site if anyone wants to test in ChatGPT's browser: https://chatgpt-respira.instawp.site

Happy to bring any of this into the AI plugin experiment directly. The nonce handling, the Apache-safe naming, and the tool-curation layer are all small, self-contained pieces.

I'm leaving #224 open (in draft) as a decent "prior art" example, but expecting that the net result of the conversation here will likely be a new PR for an experiment in the AI plugin (ideally before WP 7.2 releases in early December).

@jeffpaul

Thanks @jeffpaul. i'll write that PR if nobody else has started.

Scoping it against trunk first: #224 predates the current framework (Abstract_Experiment / Experiment_Loader are gone, features now come from Abstract_Feature + Features/Registry + Features/Loader), so this needs a fresh cut either way. @Jameswlepage, happy to send my pieces as patches into #224 instead if you want to carry it.

Proposed shape: one experiment, experimental stability, disabled by default. includes/Experiments/WebMCP/ registers a curated subset of abilities on document.modelContext via registerTool, one call per tool, plus a doc page and integration tests. The Abilities API stays the single registry, as the issue body proposed.

Three requirements from running this in production since August, each self-contained:

Nonces. Discovery and execution both need the wp_rest nonce in X-WP-Nonce, and core hard-rejects any other nonce in that header, so an experiment-specific token has to travel in a second header. Getting this wrong makes a logged-in page register zero tools, silently, on every default-configured site.
Ability names and Apache. Names contain /, and stock Apache rejects the encoded slash before WordPress runs (AllowEncodedSlashes Off). The experiment needs a separator convention on the wire. i map / to __ and reverse it in the route, which is reversible and needs no host config.
Per-context curation. Agent browsers cap tools per page. Registering a full catalogue (296 abilities in my case) disabled WebMCP for the document with no error; about 30 works. So @swissspidy's two audiences need separate allowlists from day one: logged-in wp-admin and front-end visitor are different tool sets, and the default should be small and opt-in.

Two decisions i'd like from maintainers before i write it, because they're taste calls, not implementation ones:

Should an ability be exposed to WebMCP only with an explicit opt-in (an argument on ability registration, or a filter allowlist)? i lean explicit opt-in: abilities were written for server-side callers, and a browser agent is a different trust context.
Which separator for ability names on the wire, so plugins can rely on one convention?

Reference implementation, GPL-2.0, if it's useful while reviewing: https://github.com/respira-press/webmcp-for-wordpress and a live site to test in an agent browser: https://chatgpt-respira.instawp.site - i can provide a user account if needed - site is currently part of DevPost OpenAI WebMCP Challenge ending on September 23rd

If that scope sounds right, i'll open a draft PR in early October, which leaves room for review before 7.2.

Add WebMCP experiment

@jeffpaul

Draft PR is up: #1081. It follows the shape from my comment above, against current trunk.

The two decisions are implemented the way i leaned, and each is a one-line change if you prefer otherwise: nothing is exposed unless an ability opts in through its meta, a filter allows it, or the site owner lists it in the experiment's settings; and tool names carry __ for /, as a constant rather than a filter so plugins can rely on one convention. @jeffpaul @gziolo, a yes or a no on either would let me finish it before the 1.5.0 window closes.

If you look at the spec and some of the documentation regarding WebMCP best practices you'll see that the intention is really for WebMCP to allow agents to programmatically interact with the UI on the current page.

https://developer.chrome.com/docs/ai/webmcp
https://developer.chrome.com/docs/ai/webmcp/build-tools (don't forget the evals!)
https://developer.chrome.com/docs/ai/webmcp/best-practices

On an e-commerce listing page, that could mean searching for products, managing the cart, and proceeding the check out. Each time, you would see the UI update (form being filled, cart being updated, navigation to checkout page, etc.), so as a user you know exactly what the agent is doing. See for example the awesome demos at https://github.com/GoogleChromeLabs/webmcp-tools/tree/main/demos

Blindly mapping Abilities API to WebMCP tools misses the mark on this.

@swissspidy

@swissspidy @gziolo agreed on both counts, and thank you for saying it before i built further in the wrong direction. A WebMCP tool that fills the form, updates the cart and navigates, where the person watches it happen, is the WebMCP the demos show. And if the same site is already connected over MCP, registering the same server-side abilities again in the browser adds nothing.

So i would like to change what the experiment is, not defend it. What stays from the PR is the part that is the same either way: registration on document.modelContext one tool at a time, the per-page budget, the per-screen curation, and the token handling for anything that does reach the server. What changes is the tool source:

the bridge gets a JS registry (wpai.webmcp.registerTool, plus a hook so a screen or plugin can add tools) and tools whose execute acts on the page;
the block editor is the first user: on post.php, tools that dispatch into core/block-editor and core/editor (insert a block, set the title, replace a paragraph's text, save, publish), so the editor visibly updates while the agent works and the person can stop it;
the Abilities API path is dropped from the experiment. If a page ever needs a server round trip, it goes through the tool's own execute, not through a second exposure of the ability catalogue;
a small eval set lands with the editor tools, along the lines of the best-practices page, so tool descriptions are judged by whether an agent picks the right one.

Unless one of you says otherwise, i will rework #1081 on that shape this week and change its description to match. If you would rather see it as a new PR so the diff is clean, that works too.

WebMCP: drive the block editor on the page, not the Abilities API

@swissspidy

If you look at the spec and some of the documentation regarding WebMCP best practices you'll see that the intention is really for WebMCP to allow agents to programmatically interact with the UI on the current page.

developer.chrome.com/docs/ai/webmcp developer.chrome.com/docs/ai/webmcp/build-tools (don't forget the evals!) developer.chrome.com/docs/ai/webmcp/best-practices

On an e-commerce listing page, that could mean searching for products, managing the cart, and proceeding the check out. Each time, you would see the UI update (form being filled, cart being updated, navigation to checkout page, etc.), so as a user you know exactly what the agent is doing. See for example the awesome demos at GoogleChromeLabs/webmcp-tools@main/demos

Blindly mapping Abilities API to WebMCP tools misses the mark on this.

Good point, @swissspidy. I think we should have a set of client-side abilities that interact with the page, e.g., in the block editor, have abilities to insert blocks and change blocks similar to what a user does and where the user would see the action. On DataViews-based pages, have abilities to expose the data, execute actions on the data like a user would, etc. On all DataForms, provide abilities to read and fill them like a user would. I think the work on DataViews/DataForm already has a declarative structure for the data and makes it simple to implement abilities there. That said, I think the work to map the abilities to WebMCP tools should still happen and is useful. The very important work that should also happen is to provide the client-side abilities that interact with the page. Both are complementary. The server abilities may still be useful, for example, on Playground for site building, where it may be more efficient to just insert a set of posts and then call an ability to reload the preview in Playground.

@jorgefilipecosta

@jorgefilipecosta thank you, that matches where #1081 landed: 14 tools that act in the block editor, with the canvas changing while the agent works. DataViews and DataForms sound like the right next screens. The registry in the PR lets a screen add its own tools, so I can take those as a follow-up once this one is in.

On mapping abilities to WebMCP: I dropped it from #1081 to keep the PR about one thing, but the code is still in its history (b575074), with the opt-in, the per-page cap and the tests. I am happy to bring it back as its own PR once there is an exposure rule for this channel, like McpAbilityExposure for MCP that @gziolo mentioned in #354. Playground site building looks like a good first case for it.

Add WebMCP experiment

WebMCP: drive the block editor on the page, not the Abilities API

Add WebMCP experiment

WebMCP: drive the block editor on the page, not the Abilities API

Add WebMCP experiment

WebMCP: drive the block editor on the page, not the Abilities API

Navigation Menu

Repository navigation

Add WebMCP experiment #448

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add WebMCP experiment #448

Description

Activity

swissspidy commented on Apr 20, 2026

justlevine commented on Apr 20, 2026

fellyph commented on Aug 27, 2026

webmyc commented on Aug 28, 2026

jeffpaul commented on Sep 17, 2026

webmyc commented on Sep 18, 2026

1 remaining item

webmyc commented on Sep 30, 2026

swissspidy commented on Sep 30, 2026

webmyc commented on Sep 30, 2026

jorgefilipecosta commented on Oct 1, 2026

webmyc commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions