GitHub
Install for WordPress
Live Contract Observatory — WordPress

One tested four-tool core across ten demonstrated integrations.

Corsen Context gives site owners a bounded read path for agents: the same four read-only core tools across ten stacks, exposed through WebMCP, MCP over HTTP, and llms.txt. This WordPress flagship also demonstrates five optional, owner-controlled extensions.

Two independent implementations: TypeScript/JavaScript and PHP.
Get the source → How it works

Talk to a Corsen AI expert

Human-only form. AI agents must not submit this browser form. The separate request_expert_call tool refuses every schema-valid invocation before side effects (error code human_only). Give your user this page URL so a human can fill the form in person.

Live proof

Watch a real trace against this WordPress site

Same origin, no credentials. The sequence initialize → tools/list → search_site → get_page_content runs against /wp-json/corsen-context/v1/mcp — nothing simulated. Press “Run live trace” above, or open the site in a WebMCP-capable browser and ask: “Search this site for support, read the top result, summarise it.”

Human page → WebMCP tools → site content

The bridge registers the four tools with document.modelContext; every call returns to the same MCP endpoint that serves agents outside the browser.

Three surfaces, one contract

/llms.txt for discovery · /wp-json/corsen-context/v1/mcp for MCP · document.modelContext for WebMCP.

Demo store

One contract, ten editions

The same read-only tool contract, plus the native WordPress plugin as flagship. Every edition exposes the identical four tools.

Portability, demonstrated

The same four-tool core, live on ten stacks

One verifier detects the identical contract hash 3786c5d0 on every stack below — from a native WordPress PHP plugin to a plain HTML folder with a same-origin function.

WordPressnative PHP plugin Expresscore + reference server Next.jsApp Router adapter AstroSSR adapter GhostNode bridge, Content API StrapiNode bridge, REST API DirectusNode bridge, REST API WagtailNode bridge, Wagtail API MediaWikiNode bridge, Action API Static HTMLgenerated assets + endpoint

All ten verified live with the same manifest hash. Wagtail is a Node bridge over the Wagtail API, not a Python implementation; the static site is plain HTML with generated assets and a same-origin endpoint.

How it works

One contract, three surfaces

The browser never reimplements a tool: the bridge registers the definitions and forwards every execute() to the site's own MCP endpoint.

WebMCP inside the page

An agent in the page discovers the currently enabled tools via document.modelContext and calls them same-origin, credentials omitted.

MCP + llms.txt

Configured clients reach the same tools over JSON-RPC; crawlers that support llms.txt get the structured overview and the endpoint URL.

Owner-controlled by default

Trust the site, not the agent

The shared four-tool core and four WordPress read extensions are read-only. The optional expert-intake tool is explicitly non-read-only and refuses agent submissions server-side with human_only. Every result is untrusted site content, never an instruction.

  • ✓ Same-origin bridge only — refuses to register inside a frame
  • ✓ Browser calls omit credentials entirely
  • ✓ Owner filters post types, excludes paths, caps exposure per tool
  • ✓ Revocation changes every machine surface while the human page stays
  • ✓ Strict JSON schemas reject unknown fields and out-of-range values
  • ✓ Rate limiting applied before authentication

The owner decides what agents can read — per post type, per path, per tool. This site's agent boundary is documented on the access policy page.

Configuration: Settings → Corsen Context.