Documentation / 7.3.4

MCP and browser agent tools

Understand optional plugin MCP modes, authorization, and read-only WebMCP support.

Understand optional plugin MCP modes, authorization, and read-only WebMCP support.

How it works

The shipped contract uses a revision-pinned Cybermaps conformance profile for AI Discovery Protocol 3.0 Level 3. The profile covers the manifest, bounded updates, and the four /news/* publications; it does not claim an unqualified ADP implementation level, and every publication remains conditional on its own AI Publishing setting.

OpenAPI 3.2.0 is canonical. The retained 3.1.2 document is available through explicit Accept negotiation or the documented version=3.1.2 query form, with Vary: Accept on negotiated responses. The API Catalog and generated contracts identify the exact representation served.

The established API discovery surface uses RFC 9727 and RFC 9264. The catalog contains an enriched Linkset for every advertised public API rather than one undifferentiated route list. GET /wp-json/cybermaps/v1/health is a bounded public health resource; it reports public service state without exposing private WordPress diagnostics or replacing external monitoring.

The current MCP Server Card is experimental. Its canonical resource is GET /wp-json/cybermaps/v1/mcp/server-card; the requested scanner compatibility path is /.well-known/mcp/server-card.json. The card describes optional MCP separately from OpenAPI and does not imply that a client supports the current draft. The Agentic Resource Discovery catalog is also a draft: its canonical path is /.well-known/ai-catalog.json, /ai-catalog.json is a compatibility alias, and it lists only capabilities active for the current site.

Markdown for Agents is an opt-in vendor convention, not an RFC. When enabled, eligible canonical singular, homepage, blog, and public archive URLs return bounded stored-content Markdown when text/markdown is explicitly preferred over HTML. Default requests remain HTML; both variants declare Vary: Accept. Cybermaps reports its four-bytes-per-token estimate in X-Markdown-Tokens and marks native output with X-Cybermaps-Markdown-Source: origin. It does not render theme HTML, execute shortcodes, claim Cloudflare byte parity, or emit an X-Original-Tokens value.

The existing Content-Signal header and robots declaration remain unchanged. The optional AIPREF Content-Usage attachment is disabled by default; when enabled it publishes bounded sitewide or path-specific train-ai and search preferences. ai-input remains Content-Signal-only. IndexNow submissions use the existing eligible-URL behavior and, when enabled, a durable deduplicating same-host database queue with bounded retries and batches of up to 10,000 URLs.

MCP is disabled by default and has four explicit modes: off, discovery, read_only, and operations. Current MCP 2026-07-28 Streamable HTTP uses one stateless POST endpoint. The operations tier exposes exactly five bounded tools: cybermaps.search, cybermaps.audit.run, cybermaps.static.reconcile, cybermaps.static.purge, and cybermaps.indexnow.submit. OAuth 2.1 authorization code with PKCE, consent, scoped bearer tokens, and WordPress capability checks are required. No tool edits content, settings, or general WordPress administration. ai-actions.json is descriptive metadata only and is never auto-executable.

OAuth discovery remains pure OAuth metadata. Cybermaps does not advertise OpenID Connect, does not publish an OIDC discovery document, and does not fabricate a JWKS. The default-off agent_registration_mode=user_claimed flow uses RFC 8628 device approval and requires a logged-in WordPress user to review and approve the request before any account or credential is created. Auth.md publication is enabled when MCP is enabled and registration mode is user_claimed; there is no separate Auth.md switch. It is documented as an emerging agent-registration protocol, not as an established standard.

The default-off WebMCP bridge registers only three read-only browser tools: cybermaps.search_site, cybermaps.get_page_markdown, and cybermaps.list_discovery_resources. It prefers document.modelContext.registerTool, falls back to navigator.modelContext.registerTool, and safely performs no registration in unsupported browsers. It grants no new server-side authority.

Static diagnostics report body parity separately from origin-header parity, including RFC 9111 edge policy, RFC 9530 Repr-Digest, Content-Usage, and deployment headers. Static claims are conditional on the selected Static File Engine mode and equivalent web-server/CDN routing.

The administration UI places visible maturity guidance beside the relevant controls: established RFC standards, current drafts, early protocols, experimental previews, and vendor conventions are labelled separately and link to their authoritative sources. These labels describe specification maturity, not client adoption or a promise that any crawler will use the publication.

AI Discovery Status separates configuration, advertisement, availability, body validity, and protocol conformance. When a compatibility alias works but its canonical well-known URL does not, the page identifies likely /.well-known/ interception. Core discovery mode materializes ownership-safe canonical bodies automatically; diagnostics keep body availability distinct from media-type and header conformance. Cybermaps can maintain an owned well-known rewrite block on compatible Apache/LiteSpeed installations and, after explicit authorization, its own Cloudflare rules. It does not edit nginx or Varnish configuration.