Skip to main content
WebMCP lets a browser agent discover and invoke tools exposed by the WorldMonitor page that is open in the current tab. Those tools operate the existing homepage or dashboard UI; they are not a separate data API.
WebMCP is an experimental proposed web standard. Chrome offers it through an origin trial that started in Chrome 149. ChatGPT desktop implements a current subset as Site tools in its built-in browser. APIs and host behavior can change. WorldMonitor supports WebMCP only in a visible browser page with a person in the loop.WebMCP does not replace the hosted WorldMonitor MCP server. Use the hosted server for persistent, remote, background, or headless agents and for direct access to WorldMonitor data.To test with ChatGPT, open WorldMonitor in the built-in browser in the ChatGPT desktop app. ChatGPT Work and Codex can discover the top-level imperative tools there. A normal chat on chatgpt.com or in the mobile app does not own the WorldMonitor page and cannot discover its tools. See OpenAI’s Site tools guide for current model, workspace, and rollout support.

Choose the right surface

WebMCP is not an MCP transport, MCP Apps extension, discovery server, or embedding mechanism. The hosted MCP server and MCP Apps can work without a WorldMonitor tab. WebMCP instead describes the live frontend and lets the browser agent use that frontend in place.

Availability

Production origin trial

WorldMonitor enrolls /, /dashboard, and /dashboard.html on the canonical production origin:
  • https://www.worldmonitor.app
It enrolls /dashboard and /dashboard.html on these specialized production origins:
  • https://tech.worldmonitor.app
  • https://finance.worldmonitor.app
  • https://commodity.worldmonitor.app
  • https://happy.worldmonitor.app
  • https://energy.worldmonitor.app
The root route on a specialized origin returns a permanent redirect to that origin’s enrolled /dashboard; the redirect response is not itself a WebMCP document. /?mode=agent is a separate machine-readable JSON surface and is not a WebMCP route. Preview deployments and documentation routes are not enrolled. Origin-trial tokens are time-limited. Release checks must verify the deployed response header rather than assume that a token committed earlier is still accepted.

Local development

For discovery and read-only dashboard tools, use Chrome 149 or newer:
  1. Open chrome://flags/#enable-webmcp-testing.
  2. Set WebMCP for testing to Enabled.
  3. Relaunch Chrome completely.
  4. Start WorldMonitor locally. Open /dashboard for the thirty-one-tool dashboard, not /embed. To inspect the static two-tool homepage, first run npm run build:pro, then open /pro/welcome.html. The local Vite route / loads the dashboard SPA; only production rewrites / to the welcome page.
  5. Confirm feature detection in DevTools:
The local flag replaces origin-trial enrollment for development. WorldMonitor still sends the origin-isolation and permissions-policy headers needed by the API.

ChatGPT desktop built-in browser

Follow OpenAI’s Site tools flow, not the hosted-MCP custom-app flow:
  1. Update the ChatGPT desktop app, then select a model and workspace that currently support Site tools.
  2. Open https://www.worldmonitor.app/ in the built-in browser. Use /dashboard to test the dashboard inventory.
  3. Select Site tools in the browser address bar, then select Available site tools. The homepage lists two imperative tools. The dashboard lists thirty-one.
  4. Ask ChatGPT Work or Codex to use a WorldMonitor tool while that page remains open.
  5. If no tools appear, reload the page in the built-in browser and inspect Available site tools again.
ChatGPT’s built-in browser currently discovers top-level imperative tools only. It does not discover declarative form tools or tools inside frames. As a result, search_procurement does not appear there even when its form is eligible. Use Chrome or another host that implements the declarative API to test that tool. A normal chat or mobile screenshot flow is not a WebMCP test because no WorldMonitor document is attached. Registering https://worldmonitor.app/mcp as a ChatGPT custom app tests the separate hosted MCP transport, not these page-bound tools.

Host support and cancellation

WorldMonitor registers the full dashboard inventory, then applies one cancellation class at invocation time:
On the origin-trial build, do not touch document.modelContext at all until the page has finished registering its tools. Any access taken before then — a bare property read, not just a getTools() call — wedges the page’s registration itself: the tools never appear, and every later getTools() stays pending forever. A getTools() that resolves with an empty inventory is a symptom of that, not the cause. executeTool() is unaffected, and a tool descriptor obtained before the wedge stays usable. This is a browser-side behavior, reproducible on Chrome 151.0.7922.174 against an origin-trial-enrolled page and absent when the same page is enabled through chrome://flags/#enable-webmcp-testing. An agent attaching at page load should wait for the document to finish loading before its first access, and should not poll.
Chrome 149–151 exposes registerTool() but invokes the registered callback with the input alone, not the documented execute(input, { signal }) shape. Aborting the signal passed to executeTool() rejects the caller’s promise with AbortError, but the browser cannot tell the page. Work already running on the page continues, and its effect can still land. The cancellation-required tools persist browser state, can navigate away, or can consume server-side allowance. The gate prevents those effects from starting when the host cannot cancel them. The view-state tools remain available. set_map_view, set_time_range, and focus_country also update the address bar through history.replaceState, which creates the same reloadable share state as the dashboard controls.
Browsers without the current API, including the Tauri desktop webview when it does not expose WebMCP, safely do nothing. WorldMonitor does not install a browser polyfill and does not fall back to an older draft API.

Tool inventory

Tools are page- and state-specific. The runtime source of truth is await document.modelContext.getTools(), not a cached list from an earlier page.

Homepage tools

The static https://www.worldmonitor.app/ welcome page registers two imperative tools before the dashboard SPA loads:

Dashboard imperative tools

Every dashboard variant registers the same thirty-one imperative tools. Registration is stable across sign-in and entitlement changes. Each invocation rechecks live state and the host’s cancellation support. search_dashboard returns concise descriptors rather than raw hidden dashboard state. Its opaque result keys are one-use, expire after two minutes, are bounded to the most recent 64 entries, and are invalidated when relevant runtime, authentication, entitlement, variant, or widget access changes. A stale or invalid key is denied instead of being treated as a URL or command. executable is true only when the live dashboard can run the result and the host signal on that search_dashboard call can satisfy the bound effect’s cancellation requirement. open_search_result re-checks the host signal on the open call, so a later open without a target-side AbortSignal is still denied for persistent, quota-consuming, and external-navigation results. The effect class is bound to the opaque token at issuance; callers cannot supply or downgrade it.

Declarative procurement tool

The Global Procurement panel can expose one declarative WebMCP tool: This tool requires a host that implements the declarative API. It does not appear in ChatGPT’s built-in browser. The form’s exact description is “Search official global procurement opportunities using visible filters.” It uses toolautosubmit and the same controls a person sees. Invocation makes the form visibly active, applies the filters through the normal request path, and resolves with a bounded summary of matches, availability, coverage, applied filters, and source status—not tender descriptions or hidden submission data. Reset or cancellation aborts the request and restores the visible form state. See Global Procurement Intelligence for the data contract.

Common browser-agent journeys

Discover the inventory only after the page has finished registering tools. Then use the smallest tool chain that completes the person’s request. Do not guess panel IDs, layer IDs, tab IDs, result keys, entitlements, or hidden data. Read the current page state or the appropriate catalog, invoke one bounded action, inspect its result and visible effect, then continue.

Results, denials, and errors

WebMCP returns native JavaScript values. It does not use the hosted MCP server’s { content, isError } response envelope. Imperative tool output is limited to 1,500 serialized characters. Search descriptors and other third-party-derived text are bounded and marked untrusted, but an agent must still treat them as data rather than instructions. Expected denials remain normal tool results because some browser agents remove useful page error details from rejected executions.

Human control and UI behavior

  • Imperative tools register synchronously at startup, but wait for the necessary UI or map renderer before acting. Destroying the app aborts pending work and unregisters its tools; same-document reinitialization does not create duplicates.
  • Actions go through the same UI, agent-bus, panel, and map paths used by human controls. They do not call a privileged backend shortcut.
  • Authentication, subscription entitlement, dashboard variant, mounted-panel availability, layer policy, and renderer readiness are evaluated at invocation time. A tool discovered while signed in cannot retain access after sign-out or downgrade.
  • Successful mutations remain visible: panels open, the search palette appears, map state changes, dashboard tabs change, and the declarative procurement form shows active/pending state.
  • Denied, invalid, skipped, unavailable, and expired operations return bounded outcomes or safe errors. They do not silently bypass a lock or invent a result.
  • The person can continue using the page. Existing reset, close, navigation, and cancellation controls remain authoritative.

Security and privacy

WorldMonitor follows the browser’s origin-isolated, same-origin model:
  • Production dashboard responses use Origin-Agent-Cluster: ?1 and a Permissions-Policy containing tools=(self).
  • WorldMonitor does not grant WebMCP access to another origin with fromOrigins, exposedTo, or an iframe allow="tools" delegation.
  • /embed and /embed.html explicitly send tools=(). An embedded WorldMonitor panel must expose no WebMCP tools, even when its parent page has WebMCP access.
  • WebMCP uses the person’s existing browser session. It does not accept a new API key through tool arguments or weaken panel and data entitlements.
  • get_access_context reports only account state, product tier, capability flags, and limits. It never includes names, emails, account IDs, tokens, or session details. open_sign_in opens the existing Clerk dialog and never accepts credentials.
  • Dashboard search results are treated as untrusted content and are revalidated before selection.
  • Dashboard operational telemetry is bounded: webmcp-registered records toolCount, pageSurface, and the API bucket; webmcp-registration-failed records the tool and a stable reason; webmcp-tool-invoked records the tool, outcome, and terminal reason. Dashboard search may additionally record query length, result count, and allowlisted result-type buckets. These WebMCP-specific custom properties must not include arguments, search text, result keys, returned content, URLs, tender content, or user identity. The events still use WorldMonitor’s normal Umami page and session envelope, which includes page context and may be associated with the signed-in dashboard identity; the restricted path omits automatic content-attribution properties, not normal analytics session metadata.
WebMCP is designed primarily for a local browser workflow with a person in the loop. Although browser implementations may expose pieces in other environments, WorldMonitor does not support WebMCP as a headless, unattended, cross-origin, or background automation contract. Use the hosted MCP server for those cases.

Debug with the browser API

Use the current API on document. The older navigator.modelContext surface is deprecated in Chrome 150, and the removed provideContext draft API is not supported.
getTools() returns the tools authorized for the current page in alphabetical order. In current Chrome builds, a returned descriptor’s inputSchema is a JSON string:
Invoke a discovered tool with a JSON-string argument payload:
Test browser-driven cancellation with an abort signal:
This cooperative target-side cancellation proof requires the browser to pass the invocation signal to the registered callback. On the one-argument callback implementations in WorldMonitor’s recorded Chrome 149–151 evidence, your AbortError branch still runs, but it proves only that your call was abandoned. The page never learns of the abort, so its work continues and its visible effect still lands. Whether you observe the AbortError or the tool’s normal result depends on whether the page callback happened to finish first. Treat cancellation as caller-side only on those builds. Cancellation stops work that has not reached its synchronous UI commit point. It does not roll back a viewport transition that was already issued before the signal arrived. On a browser that delivers the target-side AbortSignal to the registered callback, WorldMonitor checks that signal again before its later URL synchronization and success telemetry, so cancellation there cannot overwrite newer human input. Every shipped Chrome build through 151 omits that signal, so this suppression does not run for real users today; on those builds, treat cancellation as caller-side only, per the previous section. For a visual workflow, install Chrome’s official Model Context Tool Inspector. Use it to confirm discovery, descriptions, schemas, valid and invalid arguments, outputs, errors, cancellation, and the corresponding visible UI change. Chrome DevTools 149 also has an experimental WebMCP Application-panel inspector; that separate experiment requires both chrome://flags/#enable-webmcp-testing and chrome://flags/#devtools-webmcp-support.
The Inspector’s natural-language workflow sends prompts to an external Gemini model by default. Do not put credentials or private dashboard content into Inspector prompts. See Chrome’s WebMCP overview for the current model behavior.

Troubleshooting

For a report, include the exact page URL, host and version, tool names from one post-load inventory read, safe result or error, and the visible UI outcome. Do not include arguments that contain private data, credentials, result keys, or returned third-party content.

Maintain and release this contract

If you change the tool inventory, UI behavior, security boundary, or release checks, follow Maintain and release WebMCP. That guide owns the source map, focused verification command, same-SHA smoke checks, and compatibility policy.

Feedback and official references

Report WorldMonitor inventory, UI, permission, or entitlement problems through GitHub Issues or WorldMonitor support. Include the page URL, host and version, visible tool names, expected UI effect, actual bounded result or error, and whether the behavior reproduced in the Inspector when Chrome was the host. Never include credentials or private dashboard content.