Repository navigation
Conversation
Adds ui/sandbox-list-tools, ui/sandbox-call-tool and ui/notifications/sandbox-tools-changed to the draft specification: the Sandbox proxy, which is the only party same-origin with the View, reads the tools the View registers with WebMCP (document.modelContext) and answers the Host itself. The standard tools/list and tools/call are untouched and keep reaching Views that answer them. The `tools` app capability and the View-handled tools/list, tools/call and notifications/tools/list_changed are marked deprecated in favor of WebMCP. Includes the matching spec types and regenerated schemas. Illustrates one of the options discussed in modelcontextprotocol#797.
App.registerTool() becomes a deprecated wrapper over
document.modelContext.registerTool(): the App no longer serves the tool
over tools/list / tools/call and no longer declares the `tools`
capability on its behalf. A callback's structuredContent (or its
content) becomes the WebMCP result; isError rejects. App.oncalltool,
App.onlisttools and App.sendToolListChanged are deprecated too, and the
first two warn once per App.
Host side, AppBridge.sendSandboxResourceReady() injects a small
document.modelContext polyfill into the View HTML by default
(`modelContextPolyfill: false` opts out; a native implementation wins).
createModelContextRelay() is the helper a Sandbox proxy uses to read the
View's tools and answer the new reserved messages, and AppBridge gains
listWebMcpTools(), callWebMcpTool() and onwebmcptoolschange. listTools()
and callTool() are deprecated.
A tool result is {content: [], structuredContent: value}; a tool that
throws is an isError result.
This is a breaking change in behavior: a View on this SDK that uses
registerTool exposes no tools on a Host that has not adopted the
polyfill injection and the relay.
The sandbox proxy uses createModelContextRelay() to answer the Host's reserved tool messages from the View's document.modelContext, and the Host lists and calls the tools with listWebMcpTools() / callWebMcpTool() in a new "App tools (WebMCP)" panel. The sandbox iframe delegates the `tools` Permissions Policy feature so native WebMCP works too.
Migrates the budget-allocator, map, pdf and debug examples from app.registerTool() to document.modelContext.registerTool(), typed with webmcp-types (0.1.10, MIT, no dependencies, pinned). Tools return plain data, which reaches the Host as structuredContent, and throw to report errors. debug-server logs its WebMCP calls instead of the raw oncalltool / onlisttools handlers; three.js no longer declares a `tools` capability it has no handlers for.
Describes the move to WebMCP for Views, and what Hosts and Sandbox proxies have to adopt, including the behavior change for Views that keep using app.registerTool() on a Host without the polyfill injection and the relay.
Loads the budget-allocator, debug and shadertoy examples in basic-host and lists and calls their tools end to end: a View registering with document.modelContext, a throwing tool, and the deprecated App.registerTool() wrapper (with its single warning).
The docker targets bind-mounted the repo and ran `npm ci` in it, which left the host with Linux binaries in node_modules, and passed `-it`, which fails without a terminal. They now share scripts/e2e-docker.sh: the repo is still mounted (so snapshots are written back) but every node_modules directory is shadowed by an anonymous volume, and `-it` is only used when stdin and stdout are terminals.
@modelcontextprotocol/ext-apps
@modelcontextprotocol/server-basic-preact
@modelcontextprotocol/server-basic-react
@modelcontextprotocol/server-basic-solid
@modelcontextprotocol/server-basic-svelte
@modelcontextprotocol/server-basic-vanillajs
@modelcontextprotocol/server-basic-vue
@modelcontextprotocol/server-budget-allocator
@modelcontextprotocol/server-cohort-heatmap
@modelcontextprotocol/server-customer-segmentation
@modelcontextprotocol/server-debug
@modelcontextprotocol/server-lazy-auth
@modelcontextprotocol/server-map
@modelcontextprotocol/server-pdf
@modelcontextprotocol/server-scenario-modeler
@modelcontextprotocol/server-shadertoy
@modelcontextprotocol/server-sheet-music
@modelcontextprotocol/server-system-monitor
@modelcontextprotocol/server-threejs
@modelcontextprotocol/server-transcript
@modelcontextprotocol/server-video-resource
@modelcontextprotocol/server-wiki-explorer
commit: |
|
shouldn't this fail always in chrome that has enabled the webmcp flag? |
|
Small question while implementing the host side of this in our extension: is As far as I can read the diff, the relay's handler for that message ignores the params and returns everything from one If that's the intent, it would help to say so in the spec text, or to leave the fields out of the message, so a host author doesn't wonder whether a reply without I'm also happy to look at paging for |
|
One more thing from the host side: I can't see a way to cancel a The relay calls MCP already has |
|
A small data point on the string-or-object input question, in case it's useful. I tried it on Chrome 155 with native WebMCP: So the comment in the relay saying Chrome reports schemas as JSON strings and takes the input as one is out of date for 155. Nothing breaks, because the rule it actually uses (string input only when some schema is a string) gives the object here. It might be worth updating the comment so nobody later thinks the string form is what current Chrome wants. |
Summary
Prototype of one option discussed in #797: make WebMCP (
document.modelContext) how a View exposes tools, deprecatingapp.registerTooland View-handledtools/list. The issue is undecided, so this is meant to make that option concrete for discussion, not to merge as-is. Related: #796, #691.AppBridgeinjects a small polyfill into the View HTML (a native implementation wins). The sandbox proxy, the only party same-origin with the View, reads the tools with a newcreateModelContextRelayand answers reserved messages; Hosts call newlistWebMcpTools()/callWebMcpTool(). Results are{content: [], structuredContent: value}. Spec, basic-host, four examples and a v3 migration guide follow. The last commit (docker e2e script) is independent and can be dropped.Breaking: a View using
registerToolexposes no tools on a Host without the injection and relay. It needs a major release; no version bump here.Test plan
bun test src examplespasses (558); tsc and typedoc are clean.npm run test:e2e:dockershows the same 24 failures as a cleanorigin/mainrun (font rendering on arm64 Docker, PDF servers not starting) plus 3 new passing WebMCP tests, which also pass in Chrome 154 with native WebMCP. Not verified: other browsers, real third-party Hosts.Known limits: no image results, no size caps in the relay, native quirks handled for current Chrome only.
cc/ @liady @idosal @domfarolino