MCP Apps 2.1.0 bridges WebMCP by default, mapping page tools and app tools in both directions
MCP Apps released version 2.1.0 on November 10. Its SDK enables a WebMCP bridge by default: tools registered through App.registerTool are mirrored into document.modelContext, while tools registered by the page through WebMCP are exposed over MCP Apps tools/list and tools/call, with toolchange relayed as a tool-list change notification.
Why it matters
An interactive surface no longer has to choose between an MCP Apps tool catalog and browser-local WebMCP tools. A shared catalog can reduce duplicate adapters and let generative UI discover dynamic capabilities across an assistant host and page context. It also requires tool identity, permission, and conflict handling to remain consistent across two registration systems.
A closer look
The bridge adds no new MCP Apps wire messages and no host-side API changes. Each App can disable it with webMcpBridge:false; the default is true. The release promotes the specification's WebMCP relationship into a normative interoperability mapping and changes iframe guidance so double sandboxing is no longer mandatory when another framing architecture meets general security criteria. The pdf-server example also gains per-annotation schema validation.
Who this is for
Frontend, platform, and security teams building MCP Apps, browser-local agent tools, WebMCP integrations, or generative-UI hosts.
Original sources
Revisions & corrections (1)
— The immutable MCP Apps 2.1.0 release confirms the dated WebMCP interoperability bridge, default behavior, opt-out, unchanged wire protocol, and draft framing criteria.