Royal MCP 1.5.1 supports the WebMCP browser-agent standard on the server side, and publishes MCP Server Card, Skills Index, and OAuth Protected Resource metadata at the standard well-known paths. Cloudflare Agent Readiness scanner, Vercel is-agentic, and Chrome Lighthouse 13.3+ Agentic Browsing audit all recognize your site as agent-ready with no extra setup.
Two things ship together in Royal MCP 1.5.1: browser AI can now call your MCP tools, and every scanner that grades sites for AI-agent compatibility recognizes yours.
Through Royal MCP 1.5.0, connecting an AI to your WordPress site meant one path: an external MCP client (Claude Desktop, ChatGPT connectors, Cursor, Windsurf, mcp-remote) authenticating with an OAuth Bearer token. That path is still here and unchanged.
Royal MCP 1.5.1 adds a second path: browser-based AI agents. When a visitor is signed into your site, browser-based AI from any WebMCP-compatible bridge can call the same Royal MCP tools that Claude Desktop and ChatGPT already use, without any extra login step. Cloudflare's WebMCP bridge (developer preview shipped 2026-08-06 in Agent Readiness Labs) is the first bridge implementation shipping today. More are on the way.
The second piece: Royal MCP now publishes an MCP Server Card, a Skills Index, OAuth Protected Resource metadata, and RFC 8288 Link headers at the standard well-known paths that Cloudflare Agent Readiness scanner, Vercel is-agentic, and Chrome Lighthouse 13.3+ Agentic Browsing all check for. Sites running Royal MCP 1.5.1 pass those checks automatically. Fully backwards compatible — every existing OAuth client keeps working exactly as it did in 1.4.x.
Independent scanners from Cloudflare, Vercel, and Google Chrome all check for the same standard discovery signals. Royal MCP 1.5.1 emits them out of the box.
Cloudflare's public scanner grades sites Level 1 through Level 4 on AI-agent compatibility. Royal MCP sites clear Level 3 (Advanced Integration) automatically once the plugin is active. The Cloudflare WebMCP bridge shipped in Agent Readiness Labs on 2026-08-06.
Vercel's open-source scanner (github.com/vercel-labs/is-agentic) checks for the standard well-known discovery documents and OAuth Protected Resource metadata. Royal MCP publishes all of them at the RFC-standard paths.
Google's built-in Lighthouse audit shipped Agentic Browsing checks in version 13.3. Same discovery signals, integrated into every Chrome DevTools install. Royal MCP-installed sites score the Agentic Browsing category with no manual work.
Why "recognized" is the right word. Royal MCP does not partner with any of these scanners. It emits the standard discovery documents that every scanner in this category reads. When new scanners launch (and they will — the browser-agent category is where the entire industry is heading), Royal MCP sites already speak the shape those scanners look for.
Royal MCP writes and refreshes three JSON discovery documents at the standard well-known paths, plus emits RFC 8288 Link headers on every /mcp response.
/.well-known/mcp/server-card.jsonThe MCP Server Card. Names the server, lists the protocol revisions it speaks (2024-11-05, 2025-06-18, 2025-11-25, 2026-07-28), advertises supported capabilities, and links to the OAuth authorization server metadata. Scanners read this first.
/.well-known/agent-skills/index.jsonThe Skills Index. Enumerates the capability categories the server exposes (WordPress content, WooCommerce, GuardPress security, ForgeCache, Elementor discovery, etc.) so an agent can plan a task without loading every tool schema up front.
Link headers (RFC 8288)Every response from /wp-json/royal-mcp/v1/mcp and /mcp carries Link headers pointing scanners at the server card and skills index. Plus /.well-known/oauth-protected-resource per RFC 9728 for OAuth discovery.
External clients keep using OAuth Bearer tokens. Browser agents ride the visitor's own WordPress session with cookie authentication and a nonce check.
The WebMCP bridge in the visitor's browser sends requests with credentials: 'same-origin'. The bridge acts as the visitor would. Every safeguard the WordPress admin already relies on carries over:
X-WP-Nonce header enforced on every cookie-authenticated requestFour steps. Discovery documents already emit as soon as Royal MCP 1.5.1 is active — the toggle just opens the browser-agent auth path.
Install or update Royal MCP from WP Admin → Plugins → Add New. It is free from wp.org.
Navigate to Royal MCP → Settings and scroll to the "Browser agents (WebMCP)" section.
Flip the master toggle. The status pill shows whether a WebMCP bridge is detected on your domain.
Visit yoursite.com/.well-known/mcp/server-card.json. JSON → you are done.
WebMCP is a W3C browser-agent standard co-authored by Google and Microsoft, letting browser-based AI agents call tools registered by the current page. Royal MCP 1.5.1 supports WebMCP on the server side, so any WebMCP-compatible bridge in the browser can call your Royal MCP tools directly. Cloudflare's WebMCP bridge (developer preview shipped 2026-08-06 in Cloudflare Agent Readiness Labs) is the first bridge implementation shipping today; more are on the way.
Agent Readiness is a set of standard signals that tell AI agents and crawlers what your site can do. Royal MCP 1.5.1 publishes an MCP Server Card at /.well-known/mcp/server-card.json, a Skills Index at /.well-known/agent-skills/index.json, OAuth Protected Resource metadata at the RFC 9728 path, and emits RFC 8288 Link headers on every /mcp response. Cloudflare Agent Readiness scanner, Vercel is-agentic, and Chrome Lighthouse 13.3+ Agentic Browsing audit all recognize these signals with no extra setup.
The Cloudflare WebMCP bridge uses credentials: 'same-origin' — it rides the visitor's WordPress login-session cookies. The bridge acts as the visitor would. Royal MCP enforces a WordPress nonce (X-WP-Nonce header) on every cookie-authenticated request, so a bridge can only call tools when the visitor is signed into your site AND holds a valid nonce. External OAuth clients like Claude Desktop, ChatGPT, and Cursor keep using Bearer tokens on the same endpoint. Nothing about the OAuth path changes.
Yes. The "Browser agents (WebMCP)" section on the Royal MCP settings page has a master toggle that is OFF by default. Existing installs get zero behavior change until you flip it on. Discovery documents (Server Card, Skills Index, Link headers) are public and always emit, since they're already discoverable via /wp-json/royal-mcp/v1/mcp to any authenticated caller.
No. WebMCP cookie-auth is a second auth path alongside the existing OAuth Bearer path, not a replacement. Every existing OAuth client (Claude Desktop, ChatGPT connectors, Cursor, Windsurf, Claude Code CLI, mcp-remote, Anthropic SDK) continues working exactly as it did in Royal MCP 1.4.x. Fully backwards compatible.
Native WebMCP registration via navigator.modelContext in Chrome 149+ (currently behind an experimental flag; stable rollout later this year). This lets browsers with a built-in agent call Royal MCP tools directly, without needing Cloudflare in the middle. Also on the roadmap: deeper OAuth spec coverage including Client Identifier Metadata Documents (CIMD) so external MCP clients discover client registrations without a database round trip.
Royal MCP is free from the WordPress.org plugin directory. Install, activate, and your site starts publishing the standard discovery documents that every AI-readiness scanner checks for. Flip one toggle when you want browser AI to use your tools too.
Get Royal MCP