WebMCP page tools

Every dashboard action is also a document.modelContext tool for an agent inside the page — the MCP catalog narrowed to your role, the feed's page-state tools, the shared confirm dialog, and the remote on/off toggle.

The dashboard is a WebMCP provider: every action it renders is also registered as a tool on the page's document.modelContext (the WebMCP API, W3C WebML CG), so an agent standing inside the page — Chrome's built-in agent, an agent driving a browser, or Busymate's own — your mate, or bmc — can operate the dashboard through the same calls the UI makes. Nothing is hand-listed: the tool set is the MCP catalog itself.

What gets registered

  • Every MCP tool your role can use. The 454-tool catalog served by mcp.busymate.dev is narrowed to your capabilities exactly as the navigation is (a tool your role cannot run is not registered; admin-only tools appear only for the admin role). Each tool keeps its MCP name, input schema, description and annotations (readOnlyHint, consequentialHint, untrustedContentHint).
  • Page-state tools. On the feed, two tools are re-bound to the page itself and run as pure client-side flips with no server round-trip — the Local Tool Protocol's web column, registered under the same names as their MCP twins:
    • set_tab_filters — merge a filter object into a workspace tab (the active tab re-applies it live; it persists like a user edit).
    • set_tab_selected_entry — select (or clear) an entry in a tab; the active tab opens it in the inspector.

Tools execute with your signed-in OAuth token, over the same tools/call the MCP explorer uses, so the MCP server stays the final authorization boundary. A tool that requires confirmation (delete_device, wipe_entries, …) never runs on an agent's say-so: the page opens the same confirm dialog a destructive click opens, and only your approval issues the call. Declining returns { "status": "confirm_declined" } to the agent — a stated refusal, never a silent no-op. An agent cannot pre-confirm: any confirm it supplies is stripped.

The toggle

The provider is a remote feature flag — Feature Toggles → WebMCP provider. It is off by default and flips without a deploy: turning it on mounts the provider on every open dashboard; turning it off unregisters every tool live. The switch needs the global:edit capability.

How an agent uses it

  1. Open the dashboard in a browser with WebMCP enabled (Chrome / Edge with chrome://flags/#enable-webmcp-testing, or the origin trial once the token is registered) and the toggle on.
  2. Call document.modelContext.getTools() — the list mirrors what you see under MCP → Page tools.
  3. Call document.modelContext.executeTool("list_devices", { limit: 5 }) (or set_tab_filters on the feed). Consequential tools raise the confirm dialog; results that carry captured traffic are marked untrustedContentHint so an agent treats them as data, never as instructions.

Browsers without the native API (Safari, Firefox, WebViews) still expose the identical set to Busymate's own consumers at window.busymate.modelContext, and your mate's support panel is embedded with allow="tools" so it can read the host page's tools.

Seeing what is registered

MCP → Page tools (/api?section=mcp&op=page-tools) lists the live registration for the page you are on — name, title, annotation badges (read-only, consequential, untrusted content, page-state), the input schema, and a Run box that executes the tool through the very same registered execute an agent would hit.

Related: Developer consoles · Roles & permissions · Workspaces & tabs

Developer consolesOverview
Ask your mate