WebMCP · Lesson 3

Discover & call tools

Now you're the consumer. Turn WebMCP on with one Chrome flag, then use the Google-recommended inspector — and the raw API — to see a page's tools and call one.

You've registered tools as the author (Lesson 2). This lesson flips to the consumer: whatever reads a page's tools and invokes them — a real in-browser agent (Gemini in Chrome), or, for development, the Model Context Tool Inspector extension Chrome recommends.chrome

1 · Turn it on — the Chrome flag

WebMCP ships behind a flag for local development. Two ways to enable it:

  1. Open chrome://flags/#enable-webmcp-testing, set it to Enabled, and relaunch Chrome (Canary 146+).chrome
  2. For a real site on real users, instead register for the origin trial (Chrome 149+) and embed the token — no flag needed for visitors.

Verify it's live: open DevTools Console and check the entry point exists.

// flag on + relaunched? this should be an object, not undefined: typeof document.modelContext // → "object" // (if it's "undefined": flag not enabled, or older name navigator.modelContext)

2 · Discover & call — the raw consumer API

The consumer side mirrors MCP's two verbs, but as in-process JS calls, not JSON-RPC. Read the map:

You already know (MCP)WebMCP consumer equivalent
tools/list (JSON-RPC)document.modelContext.getTools()
tools/call (JSON-RPC)document.modelContext.executeTool(name, input)
// 1) DISCOVER — what can this page do? const tools = await document.modelContext.getTools(); tools.map(t => t.name) // → ["add_todo", "greet", …] // 2) CALL — run one, matching its inputSchema const result = await document.modelContext.executeTool("add_todo", { text: "buy milk" }); console.log(result); // → "Added to-do: buy milk"
Two positions, one registry

getTools returns RegisteredTool records — name, description, inputSchema, plus the tool's origin and window. A real agent uses the descriptions to choose a tool; then supplies input shaped by inputSchema; then executeTool runs the author's execute.spec

3 · The recommended consumer — Model Context Tool Inspector

For development you rarely poke getTools by hand. Chrome recommends the Model Context Tool Inspector extension: install it from the Chrome Web Store, open a page, and it shows you the live registry.chrome It:

The page (author, Lesson 2) registerTool(...) → browser tool registry
▼ three consumers read the same registry
Dev: Inspector extension list · call by hand · validate schema
Code: raw API getTools() · executeTool()
Real: in-browser agent Gemini in Chrome
One registry, three ways to consume it. The inspector is your microscope while you build; the agent is the production consumer.
Who actually uses this in the wild

Google says Gemini in Chrome will consume WebMCP tools, and early-adopter sites experimenting with it include Expedia, Booking.com, Shopify, Etsy, Instacart, and Target. The inspector is the dev-time stand-in for that production agent.chrome

🔧 Try it yourself (≈ 8 minutes)

  1. Enable chrome://flags/#enable-webmcp-testing → Enabled, relaunch.
  2. Install the Model Context Tool Inspector.
  3. Open any page, DevTools Console, and register the greet tool from Lesson 2.
  4. Open the inspector — greet should appear. Call it with a name; watch the string come back.
  5. Now do the same over the raw API to prove they read the same registry:
    await document.modelContext.executeTool("greet", { name: "Ada" }); // → "Hello, Ada! 👋"

Seeing the same tool through both the extension and executeTool is the "click" moment. Ask me if the inspector shows nothing — usually the flag or a stale tab.

Check yourself

Which flag enables WebMCP for local testing?
Which call is WebMCP's in-page equivalent of MCP's tools/call?
What is the Model Context Tool Inspector used for?
Primary source — read this next

The WebMCP guide on Chrome for Developers (flag, origin trial, and the inspector), and the Model Context Tool Inspector listing. Install it and inspect a tool you registered yourself.