BeeClear WebMCP AI Visibility
详情介绍:
AI visibility and WebMCP discovery for WordPress
BeeClear WebMCP AI Visibility helps WordPress sites describe public content, navigation, media, forms and selected actions in a structured way for compatible AI agents and browser clients.
The plugin adds WebMCP-style REST tools, agent discovery files, Markdown content output and OpenAPI metadata so automated clients can understand what the site offers before making requests.
It is designed for site owners, publishers, agencies and developers who want their public WordPress content to be easier for AI assistants, browser agents and discovery tools to inspect without changing the normal frontend experience for visitors.
What the plugin adds
- REST manifest: Provides a machine-readable entry point at
/wp-json/beeclear-webmcp/v1/manifest. - Agent discovery files: Adds optional
/agent-manifest.txt,/agents-manifest.txt,/agents.txtand/.well-known/api-catalogendpoints, detects whether/llms.txtand/llms-full.txtare already available, and can optionally provide WebMCP fallback output for each llms file independently. - Agent policy hints: Publishes controlled capability tokens, robots.txt cross-reference directives and optional DID / W3C Verifiable Credential identity hints with admin-side previews.
- Markdown for agents: Serves singular content as Markdown when compatible clients request
Accept: text/markdown. - OpenAPI schema: Publishes endpoint metadata at
/wp-json/beeclear-webmcp/v1/openapi. - Content discovery tools: Exposes public post search, post retrieval, post types, taxonomies, terms, menus and media metadata.
- Contact Form 7 tools: Detects Contact Form 7 forms, exposes field schemas and supports authenticated submission testing.
- Custom form definitions: Lets administrators describe frontend forms with selectors, fields, labels and field purposes.
- Custom REST functions: Exposes selected same-site REST endpoints as structured WebMCP tools. Diagnostic endpoints can be flagged as developer tools, which sets the Chrome 156
debuggingtool annotation so end-user agents filter them out. - Discovery links and headers: Adds HTML head links and HTTP Link headers for configured agent-facing resources.
- Origin Trial support: Optionally sends a WebMCP Origin Trial token as an
Origin-Trialheader and HTML meta tag for Chrome 149+ production testing. - Current browser API support: Registers page tools with
document.modelContext, keeps a compatibility fallback for oldernavigator.modelContextbuilds, runs registered tools throughexecuteTool()with the Chrome 155 object input arguments (and a stringified fallback for older Chrome), and can expose tools to configured secure cross-origin iframe hosts. - Content signals: Adds optional headers and robots.txt directives for automated content-use preferences.
- Enable or disable the integration.
- Add a Chrome WebMCP Origin Trial token for production testing.
- Configure secure origins that may discover tools when this site is embedded in an iframe with
allow="tools". - Choose which public post types are exposed.
- Enable or disable content, navigation, media, form and custom-function tool groups.
- Configure agent discovery documents and content-signal preferences.
- Detect existing
/llms.txtand/llms-full.txtfiles from another plugin or static file. - Independently decide whether WebMCP should generate
/llms.txtor/llms-full.txtfallback output. - Preview the generated
agent-manifest.txt,agents-manifest.txtandagents.txtpolicy files. - Add optional trusted issuer hints and site-specific
x-capability tokens. - Describe Contact Form 7 fields and form purposes.
- Disable selected Contact Form 7 forms from WebMCP visibility.
- Define custom forms with CSS selectors and field metadata.
- Define custom functions that proxy to same-site REST endpoints.
- Run quick checks for the manifest, discovery files and enabled tools.
安装:
Installation from within WordPress
- Go to Plugins > Add New.
- Search for BeeClear WebMCP AI Visibility.
- Click Install Now, then Activate.
- Open BeeClear WebMCP in wp-admin and review which tools and discovery files should be enabled.
- Download the plugin ZIP file.
- Upload the
beeclear-webmcp-ai-visibilityfolder to your/wp-content/plugins/directory, or upload the ZIP from Plugins > Add New > Upload Plugin. - Activate BeeClear WebMCP AI Visibility in the WordPress admin.
- Open BeeClear WebMCP and save the settings once to confirm your preferred configuration.
- Test the manifest at
/wp-json/beeclear-webmcp/v1/manifest.
屏幕截图:
常见问题:
Does the plugin change my public website design?
No. The plugin adds REST endpoints, discovery files, optional Markdown responses and discovery links. It does not replace your theme or normal frontend templates.
Are WebMCP read tools public?
They can be public if enabled in the plugin settings. State-changing tools still require the normal logged-in WordPress REST nonce/current-user context.
Do I need an Origin Trial token?
For local development, Chrome can use the chrome://flags/#enable-webmcp-testing flag. For production testing in Chrome 149 and newer while WebMCP is in Origin Trial, register your site origin in Chrome Origin Trials and paste the WebMCP token into the plugin settings. The plugin will publish it as an Origin-Trial HTTP header and an HTML meta tag on uncached pages. If a page cache, CDN or server cache serves HTML before WordPress runs, add the same header at the cache/server layer.
Can WebMCP tools work from a cross-origin iframe?
Yes, but only when the embedding page delegates permission with allow="tools" on the iframe and the embedded site lists that secure HTTPS origin in the plugin's Cross-origin WebMCP setting. Leave the setting empty for same-origin tools only.
Can I disable specific tool groups?
Yes. You can enable or disable content, navigation, media, Contact Form 7, custom form and custom function tools from the admin screen.
Does the plugin expose private posts?
No. The content tools are intended for public content. Review the exposed post-type settings before enabling public read access. Password-protected posts and pages are not exposed through public content tools or Markdown output.
Does Markdown output replace my normal HTML pages?
No. Markdown is served only for compatible requests that explicitly ask for it, or through the dedicated REST Markdown endpoint.
Can I use another plugin to generate llms.txt?
Yes. WebMCP detects existing /llms.txt and /llms-full.txt files and links to them from discovery metadata. Keep Let WebMCP generate /llms.txt disabled when another plugin or static file should own /llms.txt. /llms-full.txt has a separate fallback toggle.
Why does the llms status say "Detected external file"?
It means the public URL exists, but the response does not look like WebMCP-generated output. This is expected when another plugin or a static file serves the llms document.
Does the plugin require Contact Form 7?
No. Contact Form 7 integration is optional. If Contact Form 7 is not active, the rest of the plugin can still expose content, discovery files, OpenAPI metadata, custom forms and custom functions.
Can custom functions call external APIs?
Custom functions are limited to same-site endpoints or relative paths. The target endpoint should handle validation, permissions and business logic.
My discovery headers are missing on cached pages (WP Rocket, NGINX). How do I add them?
A page cache such as WP Rocket can serve cached HTML before WordPress runs, so headers added by the plugin through WordPress hooks are not emitted. On NGINX, add the WebMCP discovery headers at the server/cache layer.
For multilingual installs where WordPress lives under /pl and /en, define $bcwm_wp_prefix with a map in the http {} context; otherwise set it to an empty string inside server {}. Then add the directives in the server {} block or in each location that serves cached HTML. Note that if a lower-level location already has any add_header directive, NGINX does not inherit add_header from the parent context, so repeat the directives in that same location.
set $bcwm_manifest "$scheme://$host$bcwm_wp_prefix/wp-json/beeclear-webmcp/v1/manifest";
set $bcwm_openapi "$scheme://$host$bcwm_wp_prefix/wp-json/beeclear-webmcp/v1/openapi";
set $bcwm_catalog "$scheme://$host$bcwm_wp_prefix/.well-known/api-catalog";
set $bcwm_llms "$scheme://$host$bcwm_wp_prefix/llms.txt";
set $bcwm_agents "$scheme://$host$bcwm_wp_prefix/agents.txt";
add_header Permissions-Policy "tools=(self)" always;
For Chrome Origin Trial production testing, add the token registered for this exact origin:
add_header Origin-Trial "PASTE_WEBMCP_ORIGIN_TRIAL_TOKEN_HERE" always;
add_header Vary "Accept" always;
add_header Content-Signal "ai-train=no, search=yes, ai-input=yes" always;
add_header Link "<$bcwm_manifest>; rel=\"webmcp-manifest\", <$bcwm_manifest>; rel=\"service-doc\", <$bcwm_openapi>; rel=\"service-desc\"; type=\"application/vnd.oai.openapi+json\", <$bcwm_catalog>; rel=\"api-catalog\", <$bcwm_llms>; rel=\"describedby\", <$bcwm_agents>; rel=\"agent-policy\"" always;
After editing, run nginx -t and reload NGINX, then purge WP Rocket and any CDN/edge cache. Verify with curl -sI https://example.com/ | grep -Ei 'permissions-policy|link:|content-signal|vary'.
Where can I test the configuration?
Use the Tests screen under BeeClear WebMCP in wp-admin. It includes quick checks for the manifest, discovery files and common read tools.
更新日志:
0.2.4
- Added: support for the Chrome 156
toolactivatedandtoolcancelevents, which moved fromwindowtodocument.modelContext(webmcp PR #245). With console logging enabled, the start and cancellation of a declarative form tool are logged with the tool name; the listener is attached todocument.modelContextwhen it exposes theontoolactivated/ontoolcancelhandlers and towindowon older builds.
- Fixed: a custom function whose endpoint was saved as an absolute URL of this site was rejected as "not same-site" when the site was opened under another host or port (tunnel, LAN port, production domain). Absolute URLs on the site's own hosts are now saved as a path and resolved against the current home URL; previously saved values are normalized the same way when used.
- Fixed: saving the Forms screen dropped the stored settings (purpose descriptions, field purposes, signals, enabled flag) of Contact Form 7 form IDs that do not exist on the site, for example entries imported from production. They are now kept unchanged, and the screen lists them with a "Form not found" note.
- Fixed: Contact Form 7 field names were lowercased when saved (e.g.
checkbox_device-Internet-connection), so the field purpose no longer matched the field and was lost on the next save. Field names now keep their case and the characters CF7 allows; descriptions stored under the old lowercased key are still read.submit_cf7_formalso passes field names with their original case. - Fixed: a custom function input schema containing JSON escapes such as
\"or\\dwas unslashed twice and saved as{}. It is now unslashed once and saved as entered. - Fixed: a custom function endpoint on another host, or a path without a leading slash, was saved and only failed when the tool ran. On save a path gets its leading slash, and a URL on another host is rejected with an error naming the function (the previous endpoint is kept when there was one).
- Fixed: the WebMCP admin screens never showed the notices WordPress hands back after saving, so validation errors were invisible. They are now printed at the top of each screen, together with the standard "Settings saved." confirmation.
- Added: a "Developer / debugging tool" option for custom functions. Flagged functions are registered with the WebMCP
debugging: truetool annotation (Chrome 156+, webmcp PR #253) and published with it in the manifest, so general-purpose and end-user agents can filter out tools meant for testing frameworks and developer tooling such as Chrome DevTools AI assistance. - Changed: the manifest now lists
debugging: falsefor every built-in tool. None of the built-in tools are developer tools, so the browser leaves them unflagged and end-user agents keep seeing them.
- Added:
window.BeeClearWebMCPTools.executeNativeTool( name, input )runs a browser-registered tool through the native WebMCP API and resolves to its result. It is the execution companion togetNativeTools()and accepts either a tool name or a tool object. - Changed: tool execution follows the Chrome 155 WebMCP change (webmcp PRs #246/#251) where
executeTool()takes an optional JavaScript object instead of a stringified JSON DOMString. The input object is passed directly; on pre-155 Chrome Stable — which still expects stringified arguments and rejects with "Failed to parse input" — the call is retried withJSON.stringify(), so it keeps working across Chrome builds. - Fixed: removed the
scripts/update-translations.shbuild helper from the distributed plugin (it tripped Plugin Check'sapplication_detected). The release-time translation steps are now documented directly in the Translations section using standard WP-CLI commands.
- Added: a "Static file check" on the dashboard (for /llms.txt and /llms-full.txt) and the Agent policy files screen (for /agent-manifest.txt, /agents-manifest.txt and /agents.txt) that warns when a real file exists at the path and would shadow WebMCP's dynamic output. WebMCP writes no files, so this replaces a write-permission check with the inverse conflict check.
- Added: a "Download" button next to each generated discovery document (llms.txt, llms-full.txt, agent-manifest.txt, agents-manifest.txt, agents.txt and the api-catalog JSON) that exports the exact generated bytes as an attachment, so a route can be hosted as a static file if preferred.
- Added: separate "LLM file content" setting that controls which post types are summarized into the generated /llms.txt and /llms-full.txt files, independent from the post types exposed to content tools. Defaults to pages only, so the llms files describe evergreen, structural content rather than every blog post.
- Changed: rebuilt the generated /llms.txt and /llms-full.txt to the standard llms.txt shape — an H1 site name, a "> " blockquote summary, then either a "- Title: first paragraph" link list (/llms.txt) or "## Title" plus the full content (/llms-full.txt). Generator metadata lines and per-entry YAML front matter were removed; the per-item description is now the first content paragraph and is omitted entirely when a page has none.
- Fixed: HTML entities (e.g. the "[…]" read-more marker, "&") no longer leak into /llms.txt list excerpts and the /llms-full.txt YAML "description" field; they are decoded to plain text like the article body already was.
- Fixed: the describe_form tool is now published whenever either the Contact Form 7 or the custom-form tool group is enabled (previously only custom forms). submit_cf7_form points agents to describe_form, so it must stay available when CF7 tools are on but custom forms are off.
- Fixed: a genuine (non-cancellation) tool failure now rejects the
execute()promise instead of resolving with the error text as a string, so agents can tell a failed tool call apart from a successful one. - Removed: the non-standard
toolparamtitleattribute from declarative form annotation. The WebMCP declarative API only definestoolname,tooldescription,toolparamdescriptionandtoolautosubmit; browsers ignoredtoolparamtitleand the code path never actually set it.
- Changed: reading registered tools back through the Chrome native WebMCP API follows the Chrome 154 change where
RegisteredTool.inputSchema(webmcp PR #241) is now a JavaScript object instead of a stringified JSON schema. The frontend normalizes both shapes, so it keeps working on pre-154 Chrome (string) and Chrome 154+ (object). - Added:
window.BeeClearWebMCPTools.getNativeTools()returns the tools the browser actually registered withinputSchemanormalized to an object across Chrome builds.
- Changed: browser tools follow the Chrome 153 WebMCP signature
execute(input, { signal }). The cancellation signal is forwarded to every REST request the tools make, so cancelling a tool call from the browser or the agent aborts the request instead of leaving it running. - Changed: a cancelled tool call now rejects instead of returning an error string, so the agent can tell a cancellation apart from a completed call.
- Changed:
window.BeeClearWebMCPTools.unregister()cancels executions that are still running. Chrome 153 no longer does this automatically when a tool is unregistered. - Fixed: a tool call never throws synchronously any more. An already-cancelled call, unparseable tool arguments and a failing browser tool now all come back as a rejected promise, which is what
execute()is contracted to return. - Added:
window.BeeClearWebMCPTools.call( name, args, { signal } )accepts an optional signal for manual tool invocations.
- Performance: Contact Form 7 field schemas are no longer inlined into every page. Building them cost two database queries and a template scan per form on every view, including pages with no form at all. The frontend now requests them from the REST forms endpoint only when an agent asks for the form list, or when the page actually renders a Contact Form 7 form. This removes about 7.7 KB from the HTML of every page view.
- Performance: plugin settings are memoized per request. They are read from roughly thirty call sites, several of them on every front-end request, and each read re-merged the defaults.
- Fixed: reading the settings no longer writes to the database. The one-time migration that splits the two llms toggles apart is now applied in memory on read and persisted once from an admin request, instead of issuing an
update_option()from a front-end read path. - Added:
window.BeeClearWebMCPTools.initMsreports the synchronous initialization cost without turning on console logging.
- Changed: the left-hand admin menu now shows the plugin name without the "BeeClear" prefix; the page title keeps the full name.
- Added: the
get_menutool now understands menus built outside the WordPress menu system. A menu-builder plugin registers its navigation on the newbeeclear_webmcp_external_menusfilter (slug, name, nested title/url items); the tool resolves them by menu name or slug, prefers them over the flat page-list fallback when no WordPress menu exists, and every response lists all discoverable menus inavailable_menus. Location-assigned WordPress menus keep taking precedence and unassigned menus stay hidden.
- Clarified the native WebMCP registration comment to match the Chrome release timeline:
navigator.modelContextwas deprecated in Chrome 150 and removed in Chrome 152, so it now only serves as a fallback for pre-150 builds. Thedocument.modelContext || navigator.modelContextfeature detection already handled all these cases; no functional change.
- Updated native browser tool registration for the Chrome 151 WebMCP API where
document.modelContext.registerTool()returns a Promise that resolves when the tool is available across the frame tree. - Added handling for asynchronous tool registration failures so they are logged instead of surfacing as unhandled promise rejections, while keeping compatibility with earlier Chrome builds.
- Added the plugin translation domain path and generated translation template for WordPress.org language-pack workflows.
- Added frontend script translation registration so generated JavaScript translation files can be loaded when available.
- Documented the translation workflow for plugin strings and WordPress.org readme translations.
- Added Chrome WebMCP Origin Trial token support for production testing.
- Updated browser tool registration for the current
document.modelContextAPI, JSON-string tool execution arguments and optionalexposedTocross-origin iframe support. - Replaced inline admin script tags with WordPress script enqueue APIs.
- Restricted discovery REST permissions to plugin settings and manager capability checks.
- Documented external-service behavior and clarified same-site custom endpoint limits.
- Returned taxonomy terms keyed by term ID for stable agent parsing.
- Added agent policy file management for
/agent-manifest.txt,/agents-manifest.txtand/agents.txt. - Added optional DID / W3C Verifiable Credential identity hints and custom capability tokens.
- Added detection for existing
/llms.txtand/llms-full.txtfiles served by another plugin or static file. - Split WebMCP fallback generation into separate
/llms.txtand/llms-full.txttoggles. - Removed the llms content-limit setting from the admin UI.
- Improved custom forms UX with collapsible form cards, collapsible field mappings and add-new-form behavior that preserves existing collapsed state.
- Moved admin styling into
assets/admin.cssand aligned the UI with the BeeClear Marketing Source Tracking admin style. - Cleaned up inline styles and unused CSS selectors.
- Initial release.
- Added WebMCP-style REST manifest and tool endpoints.
- Added
/agent-manifest.txt,/agents-manifest.txt,/agents.txtand/.well-known/api-catalogdiscovery documents, plus optional/llms.txtand/llms-full.txtcompatibility output. - Added Markdown output for singular content and a REST Markdown endpoint.
- Added OpenAPI schema output.
- Added content, navigation, taxonomy, menu and media read tools.
- Added Contact Form 7 discovery and authenticated submission testing.
- Added custom form and custom function configuration screens.
- Added admin quick checks for discovery and tool testing.