Web MCP example

[mattzcarey]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5f9ada4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔴 Browser tools in the new todo example never become available in Chrome

The example looks for the browser's tool registry in the wrong place (document.modelContext at examples/webmcp-react/src/useWebMCPTools.ts:41), while the SDK's own WebMCP support reads it from navigator, so the page permanently reports that the feature is unavailable.
Impact: Users following this example see "WebMCP testing is not enabled" and no agent can use the todo tools, even with the Chrome flag enabled.

Mismatch with the SDK's WebMCP entry point (navigator.modelContext)

The shipped adapter in packages/agents/src/experimental/webmcp.ts:406 and :426 feature-detects and uses navigator.modelContext, and its types declare modelContext?: ModelContext on Navigator (packages/agents/src/experimental/webmcp.ts:99). The sibling example examples/webmcp/src/client.tsx also uses navigator.modelContext?.registerTool.

The new example instead declares modelContext on Document (examples/webmcp-react/src/webmcp.d.ts:33-40) and reads document.modelContext in the effect. Because the property does not exist there, the effect takes the unsupported branch (setState({ supported: false, ... })), the four imperative tools are never registered, and statusView renders the "WebMCP testing is not enabled" banner (examples/webmcp-react/src/App.tsx:60-65). The jsdom tests pass only because they install the fake object on document themselves (examples/webmcp-react/src/App.test.tsx:37-40), so they cannot catch this.

If document.modelContext really is the current Chrome surface, then the SDK adapter and the other example are inconsistent and one of the two locations must be corrected; either way the repo cannot be right in both places.

Prompt for agents

The new example reads the WebMCP registry from document.modelContext (examples/webmcp-react/src/useWebMCPTools.ts and the global type augmentation in examples/webmcp-react/src/webmcp.d.ts), but the SDK's own WebMCP adapter (packages/agents/src/experimental/webmcp.ts) and the existing examples/webmcp example use navigator.modelContext. Verify which global Chrome's experimental WebMCP imperative API actually exposes, then make the example consistent with the SDK (or update the SDK/other example if document is correct). Note that examples/webmcp-react/src/App.test.tsx installs the fake modelContext on document, so the tests will keep passing regardless of which global is wrong; the test should follow whichever surface is chosen. Consider feature-detecting both locations if the API surface is still in flux.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[pkg-pr-new]

Open in StackBlitz

agents

npm i https://pkg.pr.new/agents@2116

@cloudflare/ai-chat

npm i https://pkg.pr.new/@cloudflare/ai-chat@2116

@cloudflare/codemode

npm i https://pkg.pr.new/@cloudflare/codemode@2116

hono-agents

npm i https://pkg.pr.new/hono-agents@2116

@cloudflare/shell

npm i https://pkg.pr.new/@cloudflare/shell@2116

@cloudflare/think

npm i https://pkg.pr.new/@cloudflare/think@2116

@cloudflare/voice

npm i https://pkg.pr.new/@cloudflare/voice@2116

@cloudflare/worker-bundler

npm i https://pkg.pr.new/@cloudflare/worker-bundler@2116

commit: 5f9ada4