WebMCPScanner

Corsen Context — WordPress demo (archive)

Archived page. Until 21 October 2026 this subdomain ran the WordPress demo of Corsen Context; statements about “this site” refer to that demo. It now hosts the WebMCP Scanner.

Live Contract Observatory — WordPress

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.

WebMCP for Static Sites and Hugo: Agent Tools Without a Build Step

September 2, 2026 No Comments

WebMCP on static sites: declarative form attributes, a fifteen-line registerTool script over a Hugo JSON index, origin-trial token placement on CDNs, and the MCP-tier boundary.

Read More »

WebMCP for MediaWiki: Knowledge Bases Agents Can Actually Use

September 2, 2026 No Comments

WebMCP for MediaWiki: Action API modules as read tools, token discipline as the confirmation boundary, a gadget registration pattern, and the edit-authority line wikis won’t cross.

Read More »

WebMCP in Wagtail: The Django Guide to Agent-Callable Pages

September 2, 2026 No Comments

A Wagtail WebMCP pattern: Python decides tool registration via before_serve_page, FormPage inherits declarative tools, json_script seeds safely, and permissions stay Django’s.

Read More »

WebMCP for Directus: Permission-Aware Tools for Data Apps

September 2, 2026 No Comments

WebMCP for Directus: custom endpoints with req.accountability passthrough, flow-trigger writes, the role-matrix test, and why Data Studio sessions should stay out of the agent lane.

Read More »

WebMCP with Strapi: Headless Content Meets AI Agents

September 2, 2026 No Comments

A WebMCP guide for Strapi: why tools live in the front end, Nuxt and Astro registration, the same-origin proxy as privilege boundary, and one registry feeding browser and MCP tiers.

Read More »

WebMCP for Ghost: Making a Publication Agent-Native

September 2, 2026 No Comments

WebMCP for Ghost themes: annotated search forms, {{#get}}-seeded tools, a routes.yaml agents.json endpoint, the Portal caveat, and how the member tier keeps entitlements honest.

Read More »
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.