Skip to content

About

Any WordPress site becomes agent-ready: WebMCP site tools with staged edits, approvals and rollback. Powers the first WordPress site with working site tools in ChatGPT's browser.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

1 Commit

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 

Repository files navigation

WebMCP for WordPress

Any WordPress site becomes agent-ready in the browser. This is the WebMCP layer that powers chatgpt-respira.instawp.site, very likely the first WordPress site with working WebMCP site tools inside ChatGPT's browser — built for the WebMCP Challenge and shipped to production in Respira for WordPress v8.7.1.

Open the site in an agent browser that implements WebMCP (ChatGPT's in-app browser since 2026-08-25), sign in, and the page registers a curated set of 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, fix WooCommerce products. The person and the agent look at the same page; the agent proposes, the person approves, and every change can be rolled back.

Why this is not "just add tools"

The judges' brief for agent-native sites asks for tools that would never be UI, and collaboration where human and agent share a page. Staged-duplicate editing is exactly that shape: create-page-duplicate, approve-duplicate and reject-duplicate are meaningless as buttons, but as site tools they give an agent a safe write path with a human approval gate in the loop — on the page you are both looking at.

Architecture

┌ WordPress page (logged-in) ─────────────────────────────────┐
│ webmcp-abilities.js                                         │
│   fetch /wp-json/webmcp/v1/tools   (wp_rest nonce)          │
│   registerTool() per tool → document.modelContext           │
│   execute → POST /wp-json/webmcp/v1/execute/{ability}       │
│             (wp_rest nonce + X-WMCP-Nonce CSRF token)       │
└─────────────────────────────────────────────────────────────┘
        │
┌ WordPress Abilities API ────────────────────────────────────┐
│ bridge/class-ability-bridge.php   ability → WebMCP tool     │
│ integration/…webmcp-integration…  Respira's catalog →       │
│                                   registered Abilities      │
└─────────────────────────────────────────────────────────────┘
  • bridge/ — the browser bridge: REST endpoints, rate limiter, settings, admin page, and the front-end registration script. Vendored from code-atlantic/webmcp-abilities (GPL) at the commit in bridge/UPSTREAM_COMMIT, carrying the fixes below.
  • integration/ — the Respira side: registers the plugin's MCP tool catalog as WordPress Abilities so the bridge can expose them, with per-tool permission callbacks and annotations (readOnlyHint etc.).

The four fixes that made it actually work

Found live against ChatGPT's browser during the challenge window (each one masked the next); all are worth an upstream PR:

  1. Discovery ran anonymous. The tools fetch sent cookies without an X-WP-Nonce, which WordPress treats as an unauthenticated request: 401, zero tools registered, on every site with non-public discovery (the default). The script now sends a wp_rest nonce on the discovery fetch.
  2. Execution died at WordPress core's door. The execute call put its custom CSRF nonce in X-WP-Nonce, the header core reserves for wp_rest-action nonces — core hard-rejects the request (rest_cookie_invalid_nonce) before the route runs. Two-nonce design now: wp_rest in X-WP-Nonce authenticates the cookie, the app-layer CSRF token rides X-WMCP-Nonce.
  3. ChatGPT's modelContext is frozen and only implements registerTool. The bridge registered via one batch provideContext call; polyfilling that onto a frozen object silently no-ops, so the call threw and nothing registered. The bridge now registers tools one at a time through registerTool when it exists.
  4. Ability names contain a slash, and stock Apache rejects %2F (AllowEncodedSlashes Off) before WordPress runs, while a raw slash misses the route pattern: execution 404ed on every Apache host. The bridge sends / as __ and the route's sanitizer maps it back.

Plus one operational lesson: agent browsers enforce a per-page tool budget. 296 registered tools made ChatGPT disable WebMCP for the document entirely ("configuration exceeds supported limits"); a curated ~30-tool, page-scoped set is the shape that works — and reads better in the Site Tools panel too.

Try it

License

GPL-2.0 (see LICENSE), same as WordPress and the vendored upstream. Upstream bridge © Code Atlantic, modifications © Mihai Dragomirescu / Respira.

About

Any WordPress site becomes agent-ready: WebMCP site tools with staged edits, approvals and rollback. Powers the first WordPress site with working site tools in ChatGPT's browser.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages