[WebModelContext] Consider aligning with MCP's existing API rather than creating a new one

[MiguelsPizza]

Thanks for putting this explainer together. I maintain WebMCP, which is basically what you're proposing but using the existing MCP SDK interface. You can use it today via a script tag:

<script src="https://unpkg.com/@mcp-b/global@latest"></script>
<script>
    window.mcp.registerTool(
      "add-todo",
      {
        title: "Add Todo",
        description: "Add a new todo item",
        inputSchema: {
          type: "object",
          properties: {
            text: { type: "string", description: "The text of the todo item" }
          },
          required: ["text"]
        }
      },
      async ({ text }) => {
        // Add todo item and update UI
        return { content: [{ type: "text", text: `Added: ${text}` }] };
      }
    );
</script>

I think we should stick as close as possible to MCP's existing API. Here's why:

Dynamic tools

The provideContext approach with static tool lists doesn't handle runtime changes well. MCP's registerTool returns a handle you can clean up:

const unregister = window.mcp.registerTool("admin-tool", config, handler);

// Later, when user logs out
unregister.remove();

This is crucial for real apps where tools come and go based on state (empty cart = no checkout tool, logged out = no admin tools). This is also a very effective pattern for context management and tool bloat mitigation (two very pressing issues in the MCP ecosystem at the moment)

Don't fragment the ecosystem

MCP has effectively won with 1000s of servers and adoption from basically every major LLM interface. If browser tabs use the same protocol, they're instantly compatible with everything else. Web devs can reuse backend MCP code in the frontend. Agents can chain tools across sites without special handling. Currently With WebMCP, I can just proxy the Website tools through a web extension and native host which re-exposes the server for Hosts like Claude Desktop to use. No custom translation code is needed since I am basically just relaying MCP JSON-RPC messages.

Creating a web-specific API means every MCP client needs browser-specific code. That's a barrier to adoption and a maintenance burden on those building tooling around this api.

WebMCP can serve as a testing ground for this approach if that helps. We have working implementations and a pretty active ecosystem considering I only open sourced it a few weeks ago. Happy to collaborate.

[bwalderman]

Hi @MiguelsPizza. Thanks for sharing this feedback. This proposal has graduated to https://github.com/webmachinelearning/webmodelcontext. That's going to be the correct venue to collaborate going forward.

I appreciate the suggestion about dynamic tool handling. Being able to change the toolset based on application state is one of our goals, but I'm open to alternatives when it comes to exact API shape.

The Web Model Context API is intended to complement MCP, not replace it. The exact way that tools are exposed to agents is still an active area we are investigating. For example, this could take the form of an MCP server embedded in a browser, or browsers may provide primitives like new Web Extension or DevTools Protocol APIs that external apps can use to query the tools and re-expose as MCP.

Please feel free to reopen this issue at the new repo to continue the discussion.