Skip to main content
The WebMCP proposal and MCP-B packages evolve on separate schedules. The Community Group draft owns the proposed browser API. MCP-B package references own the behavior shipped by this project. The phrase strict core describes MCP-B’s portable package boundary. It is not a second definition of the WebMCP proposal. Keeping that boundary narrow lets libraries publish tools through native implementations or the polyfill without depending on an MCP server or transport. The live draft owns the exact ModelContext members and signatures. MCP-B may retain compatibility types or adapters while browser implementations converge. Do not infer proposal status from where a method appears in an MCP-B type.

​
Why the extension boundary exists

BrowserMcpServer adds listTools(), prompt and resource registration, and a composed official MCP server. Transports, iframe routing, and the local relay connect that server to explicit MCP clients. These capabilities solve MCP-B integration problems; they are not browser API methods. Protocol-specific features remain available through BrowserMcpServer.mcpServer. Keeping them behind the composed server prevents the browser surface from becoming a second copy of the MCP SDK. Sites that only publish browser tools can use the portable layer. Applications that need prompts, resources, bridges, or desktop MCP clients use the extension layer. See Runtime layering for the composition model and Choose a runtime for package selection.