[FEATURE] WebMCP tool discovery in Claude in Chrome — revisiting #30645 with production implementation data

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

#30645 requested WebMCP discovery/invocation for Claude in Chrome. It was auto-closed as stale in April and locked, so per the stale-bot's instruction I'm filing fresh and referencing it here.

The gap is unchanged — reproduced this week against my own production site: the extension surfaces nothing from navigator.modelContext. The tools are reachable only if the model is explicitly instructed to evaluate the API via page scripting. Invocation works; discovery doesn't exist. The extension falls back to screenshot/DOM interaction even when the page publishes a structured tool surface.

What changed since March: navigator.modelContext is no longer a Canary flag — it's in a public origin trial in Chrome 149 (through 156, ending Nov 2026). The original thread's "production rollout timeline is unclear" objection is resolving, and production sites exist now: I maintain one (tradesite.dev, registered in the origin trial) with an anonymous discovery surface live today — no login needed to test discovery. See Additional Context.

Proposed Solution

Same shape as #30645: discovery (query navigator.modelContext on connect, expose registered tools as first-class MCP tools) and invocation (structured calls, structured JSON responses). Four findings from running a production WebMCP surface that bear on the design:

1. Dynamic tool lists are the norm, not an edge case. My workspace gateway registers/unregisters tools as the user moves between pages of an SPA — no navigation event fires. "Re-scan on navigation" is necessary but not sufficient; honor tools-changed callbacks rather than snapshotting at page load.

1. Expect gateway-multiplexed tools. Real sites converge on a few action-multiplexed tools with built-in help/list_actions (mine: 43 global + 40 workspace actions across two gateways) rather than dozens of micro-tools. Discovery UX shouldn't assume one-tool-per-capability.

1. Passive context tools are load-bearing. Cheap read-only tools (app_context, current_state) exist specifically as orientation/precondition reads before mutating calls. Surfacing tools without distinguishing read-only from mutating loses this pattern — worth honoring in the permission UI.

1. Don't use a11y-tree side channels for discovery. An earlier iteration of my site exposed an sr-only tool catalog for tree-walking agents; it leaked to screen readers and was pulled after an audit. Native discovery makes such hacks unnecessary — which is the point of this request.

Alternative Solutions

What I ship today because discovery is missing: a fallback bridge behind ?expose-agent=1 — a window global plus an inert JSON catalog in a <script type="application/json"> tag — solely so non-WebMCP agents can be pointed at the tools when instructed.

Site-side polyfills/SDKs (suggested repeatedly in the old thread) cannot close this gap on their own: they register tools, but the extension still doesn't discover them. Native discovery support would let sites delete these bridges entirely.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

1. User opens tradesite.dev (logged in) with Claude in Chrome and asks: "Build a 3-bar momentum strategy and backtest it over the last 30 days."
2. Today: screenshot → find element → click → type loops over a node-graph strategy editor. Slow, fragile, token-expensive.
3. With discovery: Claude reads tradesite_current_state (read-only precondition), then calls gateway actions to compose the blocks and run the backtest — a handful of structured calls with verifiable JSON at each step.

The live surface: 5 tools + 1 registered prompt via @mcp-b/global 1.6.4, loaded on idle so agent tooling never affects first paint.

Additional Context

• Predecessor: #30645 (auto-closed stale, locked) — this issue supersedes it with production implementation data, per the stale-bot's instruction.
• WebMCP W3C spec: https://github.com/webmachinelearning/webmcp
• Chrome origin trial: WebMCP, Chrome 149–156 (ends Nov 16, 2026). tradesite.dev is registered and serving a token.
• Test access, live now: a clean anonymous profile hitting https://tradesite.dev gets a working discovery surface — tradesite_app_context (returns signed-out context) and the tradesite_app gateway (help/list_actions fully functional; account-gated actions return a structured account_required refusal with zero data, schema validation first). ?expose-agent=1 additionally enables the non-WebMCP fallback bridge described under Alternatives.

const mc = navigator.modelContext;
(await mc.listTools()).map(t => t.name);
// → 3 tools, including "tradesite_goto"

await mc.callTool({ name: 'tradesite_goto', arguments: { page: 'dynamic-tool-test' } });
(await mc.listTools()).map(t => t.name);
// → "tradesite_dynamic_probe" appeared — client-side SPA route change, no browser navigation event

await mc.callTool({ name: 'tradesite_goto', arguments: { page: 'login' } });
(await mc.listTools()).map(t => t.name);
// → probe gone; calling it now throws "Tool not found"