Framework Guide · WebMCP · WordPress

WebMCP for WordPress: making the world’s most-used CMS callable by agents

Roughly forty percent of the web runs on WordPress, and almost none of it is usable by an AI agent — only readable. Agents scrape HTML, guess which button is a cart, fill forms pixel by pixel. WebMCP is the emerging standard that ends the guessing; applying it to WordPress means answering a distinctly WordPress question: on a platform that is ten thousand architectures in one costume, which layer owns the agent surface? This article maps the three real surfaces — theme (declarative), plugin (browser bridge), and headless (server-side MCP over wp-json) — and shows a production endpoint you can call right now.

Fact-checked and updated on September 2, 2026 (WordPress 6.x REST Handbook). Primary sources are cited at the end of the article.

First, the fork that decides everything

Two protocols share a name family and a mission, and conflating them is how WordPress sites end up with a demo that never ships:

• WebMCP (W3C Web Machine Learning Community Group) is a browser API: pages register tools via document.modelContext.registerTool() or annotate <form> elements; an in-browser agent — Gemini in Chrome, via the Chrome 149–156 origin trial ([Chrome for Developers](https://developer.chrome.com/docs/ai/webmcp)) — calls them while the tab is open, executing with the logged-in visitor’s session ([specification](https://webmachinelearning.github.io/webmcp)).
• MCP (Model Context Protocol, Anthropic) is a server protocol: an always-on endpoint speaking tools/list / tools/call, reachable from Claude Desktop, Cursor, Windsurf — clients that never render your page.

Most WordPress “agent traffic” today is not a visitor’s Gemini tab; it is headless agents crawling, purchasing and ingesting. That traffic needs the MCP side — exposed from WordPress — while the browser layer delivers the same contract to the in-tab user. One registry, two transports.

Surface 1 — the theme: declarative forms, no plugin, no build

Every WordPress site ships forms — search, contact, WooCommerce-adjacent, event registrations — and the Declarative API converts them into agent tools with attributes alone, the browser synthesizing the JSON Schema from the markup ([explainer](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md), mechanics in our Declarative API reference). WordPress makes it theme-global via a filter:

// functions.php — annotate the built-in search form
add_filter( 'get_search_form', function ( $form ) {
    return str_replace(
        '<form ',
        '<form toolname="site-search" tooldescription="Searches this site. Returns matching posts and pages."',
        $form
    );
}, 20 );

Classic theme, block theme, Elementor-rendered page — WordPress ultimately emits plain HTML, and the browser reads HTML. This is the lowest-risk agent-readiness change a site owner can make today: no JavaScript executes, no attack surface changes, and the semantics travel with the markup your SEO plugin already curates. The spec’s explainer positions declarative forms explicitly as structured data for agents — crawlable semantics without executing code, which for a content site is the entire argument.

Surface 2 — the plugin: an MCP endpoint via wp-json

WordPress core provides the exact extension point the serious architecture needs. register_rest_route(), invoked on rest_api_init, binds a namespace + route to a callback with its own permission callback and argument schema — the mechanism behind every core REST endpoint ([REST API Handbook — Routes and Endpoints](https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/); [function reference](https://developer.wordpress.org/reference/functions/register_rest_route/)):

add_action( 'rest_api_init', function () {
    register_rest_route( 'acme/v1', '/mcp', array(
        'methods'             => 'POST',
        'callback'            => 'acme_handle_mcp',
        'permission_callback' => 'acme_mcp_permissions',   // API key / application password — fail closed
        'args'                => acme_mcp_arg_schema(),
    ) );
} );

function acme_handle_mcp( WP_REST_Request $req ) {
    switch ( $req['method'] ) {
        case 'tools/list': return rest_ensure_response( acme_tools_list() );
        case 'tools/call': return acme_execute_tool( $req['params'] );
    }
}

WordPress’s object model maps onto agent tools almost one-to-one: WP_Query becomes search_site, WooCommerce product CRUD becomes add_to_cart and place_order, ACF fields become typed schema properties, and authentication rides core’s own application-passwords controller. Cache tools/list in your object cache; the schema is stable between publishes.

The live case study: this site’s own endpoint

Rather than pseudocode, inspect a working deployment — this very site runs its agent surface on the endpoint webmcp.corsen.ai/wp-json/corsen-context/v1/mcp, served by our Corsen Context plugin. Its design is instructive precisely because it makes the hard calls visible:

1. Schema honesty. tools/list publishes every capability with full JSON Schema — including the flagship product’s purchase tool, which the server deliberately refuses from the agent lane. The refusal is a governance decision enforced in the call layer, returned as the tool’s structured result — not a hidden capability.
2. Contract versioning. The published toolset is pinned by content hash in release notes; integrators can pin against it and CI can detect drift — the discipline missing from almost every “AI-ready” WordPress claim.
3. The browser bridge. The same registry is projected into document.modelContext on site pages via our @corsen-context/core package, so in-tab agents and desktop agents operate on identical contracts — the “one registry, two transports” principle, shipped.

Surface 3 — headless WordPress: the registry moves, the source of truth does not

In headless deployments (Next.js or Astro consuming wp-json), the browser-WebMCP layer physically lives on the front end — see our Next.js and Astro guides — while WordPress serves data and MCP. The failure mode to design against is two teams maintaining two tool lists; the fix is generating the browser registrations from the WP-side registry at build time. This is the architectural spine of the whole series, and WordPress’s build-tooling maturity (Composer scripts, CI, GitHub Actions) makes it a routine pipeline, not a research project.

The security conversation WordPress is already fluent in

WebMCP ships no auth, no approval flow, no audit log — the spec’s security section is candidly a draft, and Chrome’s own agent-security guidance stops at warning about prompt injection ([developer.chrome.com/docs/agents/security](https://developer.chrome.com/docs/agents/security)). WordPress compensates with fifteen years of governance muscle:

1. Map tools onto capabilities, not invented tokens. current_user_can( 'edit_posts' ) and custom-post-type capability maps already model your organization; an MCP tool that trusts a caller-supplied role string is a backdoor with good manners.
2. Fail closed at the REST edge. rest_cookie_invalid_nonce fallbacks and missing permission_callbacks are how blog-tutorial endpoints become CVEs — the handbook’s own examples require them for a reason.
3. Let your WAF be part of the launch plan. Agent traffic means JSON POSTs to an unusual namespace; Wordfence, LiteSpeed and Cloudflare rules default to suspicious. Verify the allow-rule with a real tools/call before announcing support, not after.
4. Audit through the stack you already run. wp-crontrol-style tooling, admin audit plugins, and named endpoints make every tools/call a legible server event — the exact property the browser API leaves unspecified.

What ships when: an honest roadmap

FAQ

Conclusion

WordPress became dominant by letting non-specialists publish. WebMCP is the same bet replayed for the machine audience: declarative attributes make every theme agent-legible this afternoon; register_rest_route makes every plugin a potential agent platform; and the CMS’s deep governance culture — capabilities, nonces, audits — is exactly the layer the specification leaves blank. The sites that treat agents as a first-class reader, with a versioned contract and enforced policy, will own the agent channel the way WordPress blogs owned the first decade of search traffic.

Primary sources

1. developer.wordpress.org — Routes and Endpoints.
2. developer.wordpress.org — register_rest_route().
3. webmachinelearning.github.io/webmcp — W3C CG specification.
4. WebMCP — Declarative API explainer.
5. developer.chrome.com/docs/ai/webmcp — origin trial.
6. developer.chrome.com/docs/agents/security.
7. Live worked example: webmcp.corsen.ai/wp-json/corsen-context/v1/mcp — Corsen Context plugin endpoint.