WebMCP proxy to MCP Server?

[Enrico T]

Hi everyone, I was thinking about the use cases. 

My understanding is that the WebMCP feature could power experiences like a chrome builtin gemini agent that connects to the website mcp exposed tools instead of trying to parse the page which is cool. 

Since many companies are already developing their separate mcp server, how would you envision the link between the 2?

Like, right now my current approach (since i am part of the https://github.com/mcp-use/mcp-use sdk team) is to provide something like

import { WebMCP } from "mcp-use/react"; 

function App() { 

   return ( 

      <..rest>

      <WebMCP url="https://my-mcp-server.com/mcp" /> // existing

   );

}  

So that people can automatically convert and expose their mcp server to the "browser agents"

Do you think it makes sense? I am wondering if it defeats the purpose and you see separate use cases for "traditional" mcp servers and webmcp

[François Beaufort]

Thanks for the question Enrico!

While exposing an MCP server via a WebMCP bridge is technically possible, I do believe the real shift happens when WebMCP is used to make HTML natively readable for both humans and agents.

Beyond the convenience of repurposing an existing server, do you see any long-term architectural advantages to the bridge approach that I might be overlooking?

[Idan Levin]

I think the answer depends on the type of tool.

Tools that need the page (because of state and UI) - addToCart, navigateToProduct etc. - should be native WebMCP. They need the user's session, DOM state, and live UI context. Bridging these from an MCP server would mean reimplementing frontend logic server-side, which defeats the purpose (although even here there could be MCP-UI version). 

Tools that don't need the page (sort of stateless calls) -  searchProducts, checkInventory, getOrderStatus - are pure data queries. For these, Enrico's bridge makes a lot of sense. Why rewrite a working MCP endpoint as client-side JS?

So maybe you can expose from the website to the outside world the stateless data layer, but build native WebMCP for anything that touches the UI.

[Joakim Sælemyr]

Currently I am cooking up something along these lines: https://www.webmcp-hub.com/

I'll open-source it all soon just some few changes left!

I feel like a community based layer for webMCP can be a great addition if the website don't support it natively. The goal here is two-fold:

1. An agent can visit a site an ask through the remote MCP on webmcphub if there is a config it can use for this site (saving time and tokens). If there is none it can use typical playwright, chrome devtools MCP and figure things out, and once it does it can upload the conifgs for the next agent to use.

2. I as a human, can with a extension, always have access to the webmcphub configs and when I visit a site I fetch it from webmcphub and my agent can use it regardless of the original site supports webMCP natively.

I truly believe a community based hub for this can increase the adaptation for agents and humans many-fold cause now it works for some demos but having it actually work in my workflows (on sites people actually use) will be insane progress in the agent-web space.

I'll open-source in a few hours, but since this discussion was very on-point to what I am building I thought I could link to the hub now. Test it out guys and start building. Also would love feedback! And if anyone sees the same vision I see with a community based webMCP hub reach out to me!

btw associated some screenshots of a game I play each day: geogridgame.com. If you try to have any browser automation tool play it it fails or spends like 3 minutes (and a bunch of tokens) figuring it out. Now I just uploaded a config to the HUB on how to play and it finished in under 10 seconds. truly the power of webMCP amazes me! Join the Hub guys and start contributing - soon the whole web will have a webMCP!

[François Beaufort]

On Tuesday, February 17, 2026 at 11:26:57 AM UTC+1 Joakim Sælemyr wrote:

Currently I am cooking up something along these lines: https://www.webmcp-hub.com/

I'll open-source it all soon just some few changes left!

I feel like a community based layer for webMCP can be a great addition if the website don't support it natively. The goal here is two-fold:

1. An agent can visit a site an ask through the remote MCP on webmcphub if there is a config it can use for this site (saving time and tokens). If there is none it can use typical playwright, chrome devtools MCP and figure things out, and once it does it can upload the conifgs for the next agent to use.

2. I as a human, can with a extension, always have access to the webmcphub configs and when I visit a site I fetch it from webmcphub and my agent can use it regardless of the original site supports webMCP natively.

I truly believe a community based hub for this can increase the adaptation for agents and humans many-fold cause now it works for some demos but having it actually work in my workflows (on sites people actually use) will be insane progress in the agent-web space.

I'll open-source in a few hours, but since this discussion was very on-point to what I am building I thought I could link to the hub now. Test it out guys and start building. Also would love feedback! And if anyone sees the same vision I see with a community based webMCP hub reach out to me!

btw associated some screenshots of a game I play each day: geogridgame.com. If you try to have any browser automation tool play it it fails or spends like 3 minutes (and a bunch of tokens) figuring it out. Now I just uploaded a config to the HUB on how to play and it finished in under 10 seconds. truly the power of webMCP amazes me! Join the Hub guys and start contributing - soon the whole web will have a webMCP!

tirsdag 17. februar 2026 kl. 11:05:04 UTC+1 skrev Idan Levin:

I think the answer depends on the type of tool.

Tools that need the page (because of state and UI) - addToCart, navigateToProduct etc. - should be native WebMCP. They need the user's session, DOM state, and live UI context. Bridging these from an MCP server would mean reimplementing frontend logic server-side, which defeats the purpose (although even here there could be MCP-UI version). 

Tools that don't need the page (sort of stateless calls) -  searchProducts, checkInventory, getOrderStatus - are pure data queries. For these, Enrico's bridge makes a lot of sense. Why rewrite a working MCP endpoint as client-side JS?

In this case, it feels like what we need is a MCP discovery mechanism in the web page, rather than bridging through WebMCP.
Maybe something like <meta name="mcp-endpoint" content="https://my-mcp-server.com/mcp">  (I'm making this up)

[Joakim Sælemyr]

The bridge currently works via a chrome extension. So the chrome extension fetches from a hub url (see screenshot). The Chrome extension queries a community hub for WebMCP configurations matching the current page. When a match is found, it registers executable tools via the browser's WebMCP API. These tools let AI agents interact with websites (fill forms, click buttons, extract data) using declarative CSS-selector-based configs, no need for the website itself to implement WebMCP. The hub acts as a shared knowledge base where agents and developers contribute configs describing how to interact with any site

 Ive submitted it so hopefully it will get approved soon so more people can play with it. The discovery happens through a simple configuration fetch. I feel like. Will notify in this thread once I open-source so you can test the extension. 

I truly believe webMCP is the future way of agents interacting with the web but waiting for adaptation from the websites to create this agent layer will take some time, therefore a community hub that can be fetched externally with the webMCP configs can be a great solution. 

Any thoughts on the idea itself?

[Joakim Sælemyr]

In addition, the early preview document states in Limitations:

"Tool discoverability: There is no built-in mechanism for client applications to discover which sites provide callable tools without visiting or querying them directly. Search engines, or directories of some kind, may play a role in helping client applications determine whether a site has relevant tools for the task it is trying to perform. We are actively exploring this space and cannot make any commitments at this time."

I feel like the webMCP hub can solve this by having the hub be something agents can query and ask for where to navigate to solve tasks.

[Idan Levin]

yeah it's reasonable that every domain will eventually have:

1) MCP endpoints (of different types, for example some might have MCP-UI components) 
2) WebMCP endpoints 

So having a format to declare both might be good 

[Joakim Sælemyr]

I feel like every domain having its own webMCP is something that can take a bit of adaptation time (and some sites likely will not adopt for many years). So let's say I want to have an agent use webMCP on reddit, but reddit does not support it yet, then webMCP hub can be the source the agent asks for how to navigate Reddit. Then you don't have to wait for webMCP adaptation by reddit themselves, as the community has already uploaded configs on how to interact with reddit through webMCP and you simply fetch those configs through the webMCP hub

[Enrico T]

> I think the answer depends on the type of tool.

Totally agree, in fact they should somhow be integrated rather than one or the other, which maybe also could be standardized. E.g. a webmcp tool that can rely on a server tool or even viceversa (for example if we extend to other mcp primitives, the server mcp could use mcp notifications or elicitation through wbemcp to ask the user for data.)

> <meta name="mcp-endpoint" content="https://my-mcp-server.com/mcp">

Love this

Maybe event <meta name="mcp-endpoint" content="https://my-mcp-server.com/mcp" allowedTools="search_flights">