WebMCP: the agent is on the page now. And the draft finally travels.

For a year the shape of this product was a connector. Your WordPress site on one end, an AI agent on the other, MCP in the middle. On August 25th the ChatGPT desktop app shipped WebMCP support in its new in-app browser, and the shape changed: the agent is no longer on the other end of anything. It is standing on the same page as you.

What that actually means

Open a Respira-powered WordPress site inside ChatGPT's browser and sign in. The page itself registers a set of site tools on document.modelContext: read the site's context, list and read pages, stage an edit as a reviewable duplicate, approve or reject it, audit SEO and readability, find and fix WooCommerce catalog gaps. No server-side connector, no OAuth dance, no setup. The page carries its own tools, and any WebMCP-capable agent browser can pick them up.

The agent-only tools are the point. Approve-duplicate and reject-duplicate would be meaningless as buttons on a page. As site tools they give the agent a safe write path with a human approval gate, on the page you are both looking at. Nothing goes live without a yes, and everything rolls back.

As far as i can tell, this made the demo studio site the first WordPress site with working WebMCP site tools in ChatGPT. The whole layer shipped to production in Respira for WordPress v8.7.1 the same day it started working, so paying customers run this code today. The patched bridge is open source at respira-press/webmcp-for-wordpress (GPL), and the entry is in for OpenAI's WebMCP challenge.

Five bugs between the spec and a working page

WordPress already had the ingredients: an Abilities API, and an open-source bridge (code-atlantic/webmcp-abilities) that maps abilities to WebMCP tools. Respira registers its production tool catalog as abilities and the bridge exposes them to the page. On paper, done. In a real agent browser, nothing worked, and finding out why became the project. Five bugs, each one masking the next.

Tool discovery ran as an anonymous visitor, because the fetch sent cookies without WordPress's REST nonce: 401, zero tools, on every default-configured site. Execution then died at WordPress core's door, because the bridge put its own CSRF token in the header core reserves for its nonce, and core hard-rejects a foreign nonce there. ChatGPT's modelContext turned out to be a frozen object implementing only registerTool, so the bridge's batch registration call threw without a trace. Ability names contain a slash, and stock Apache rejects an URL-encoded slash before WordPress even runs, so execution 404ed on every Apache host. i debugged all of this blind, with an on-page diagnostic badge, reading screenshots taken from inside ChatGPT's browser because that was the only ground truth available.

Then the last wall, and my favourite: registering the full catalog of 296 tools disabled WebMCP for the page entirely. No error, no warning. Agent browsers have a per-page tool budget, and the fix was editorial rather than technical: a curated, page-scoped set, eighteen tools on the demo site. Fewer, better-scoped tools beat an exhaustive catalog. That lesson is now feeding back into the ecosystem: the bridge fixes are reported upstream, and the field notes went to WordPress core's WebMCP experiment discussion.

The other half: a draft you can actually send to someone

Watching people use the staged-edit flow exposed a gap that had been there all along. The agent stages a change as a duplicate, and the duplicate is a WordPress draft, which means the preview link only works for someone logged into wp-admin. The person whose yes actually matters, a client, a colleague, a reviewer, usually has no WordPress login and never will.

So staged drafts now return a share link. It is a signed, tokenized URL: it renders that one draft, to anyone who has the link, with no login and no account. It grants nothing else. It expires after 14 days by default. And it dies with the review: rejecting the staged change trashes the duplicate, and a trashed draft will not render for anyone, token or not. Approve, and the link's job is done because the change is live.

The mechanism is deliberately boring. The token is an HMAC signed with the site's own salt, the draft is lifted to visible in memory for that single request, and nothing is stored anywhere. There is no table of share links to leak, nothing to clean up, nothing to revoke beyond waiting out the clock or rejecting the draft.

What a real agent taught me about API design

The first version put the share link in the response as a preview_url field, next to a dozen other fields. Then i watched ChatGPT stage an edit, get asked for a preview link, and confidently hand back the plain page URL instead, the login-gated one, because that field came first and looked like the answer. The link was right there in the JSON. The model quoted the wrong field.

The fix says something about building for agents: the share link now also lives in the human-readable message, the sentence every agent echoes back to its user. "Share preview (no WordPress login needed, valid until September 11): link." Structured fields are for programs. Messages are for models. If you want an agent to relay something, put it where the agent is already looking.

Try it on your own site

WebMCP has shipped with Respira for WordPress since v8.7.1, enabled by default. Open your own site inside the ChatGPT desktop app's browser while signed in to WordPress, and ask what site tools the page has. Fresh installs expose a small read-mostly set; you choose which Respira tools to add on the WebMCP screen in wp-admin, and the per-page budget is exactly why that screen exists. The demo studio site you may have seen in the challenge entry stays reserved for judges and plugin reviewers, so its sign-in is not public.

Share links ship to every site in the next plugin update. If you run agents against WordPress and want the staged-edit-plus-share-link flow for client work, that is exactly the case it was built for: the agent proposes, the client clicks a link, you approve, and the site never showed anyone a broken page.