[FEATURE] WebMCP support in Claude Chrome Extension

Resolved 💬 7 comments Opened Mar 4, 2026 by Panthevm Closed Apr 8, 2026

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

The "Claude in Chrome" extension interacts with websites via screenshots and DOM snapshots — fragile, token-expensive, and semantically blind to what the site can actually do.

The W3C WebMCP spec (navigator.modelContext) lets websites register structured callable tools. Chrome 146 Canary already ships an early preview behind a flag. The community fork @mcp-b/chrome-devtools-mcp proves the concept works via CDP. But the Claude Chrome Extension has no way to discover or invoke these tools.

Proposed Solution

Add WebMCP discovery and invocation to the Claude Chrome Extension:

  1. Discovery: When connected to a page, query navigator.modelContext for registered tools (either native in Chrome 146+ or via the @mcp-b/global polyfill). Expose discovered tools as first-class MCP tools available to Claude Code.
  2. Invocation: Allow Claude to call WebMCP tools by name with structured parameters, receiving structured JSON responses — bypassing the need for screenshot/click/type workflows.
  3. Dynamic updates: Re-scan tools on navigation, detecting when pages register or unregister tools.

This would complement the existing extension capabilities (screenshot, click, type) with structured tool interaction when websites support it.

Alternative Solutions

  • Use @mcp-b/chrome-devtools-mcp fork — works today but requires a separate Puppeteer-managed Chrome instance, losing the key advantage of "Claude in Chrome": operating in the user's real authenticated session with cookies and login state.
  • Use Chrome DevTools MCP (Google upstream) + --autoConnect — separate browser context, no WebMCP support in upstream anyway.
  • Wait for native Chrome integration — Chrome 146 Canary has navigator.modelContext behind a flag, but production rollout timeline is unclear, and this doesn't help the extension discover/invoke the tools.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

  1. An e-commerce site registers WebMCP tools: searchProducts, addToCart, checkout
  2. User opens the site in Chrome, logged in with their account
  3. User runs claude --chrome and asks: "Find all wireless headphones under $100"
  4. Claude discovers the searchProducts tool with its JSON schema
  5. Claude calls searchProducts({ query: "wireless headphones", maxPrice: 100 }) — a single structured call
  6. The tool executes within the user's authenticated session and returns structured JSON
  7. Claude presents the results

Without WebMCP, Claude would need to: take a screenshot → find the search input → type → click → wait → screenshot again → visually parse results — multiple rounds of expensive, fragile interactions.

Additional Context

  • WebMCP W3C Spec — co-authored by Google and Microsoft engineers
  • Chrome 146 Canary early preview — behind chrome://flags → "WebMCP for testing"
  • @mcp-b/chrome-devtools-mcp — community fork proving the concept works via CDP
  • @mcp-b/global — polyfill (v1.5.0) enabling WebMCP on any browser today
  • WebMCP reduces token usage by ~90% compared to screenshot-based browser interaction
  • The security model aligns with the extension's existing approach: tools inherit the user's browser session, with browser-mediated permission prompts

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗