When the Website Has Its Own MCP Tools — WebMCP in Local and Remote Browser
TL;DR
- Local Browser and Remote Browser now expose browser_list_webmcp_tools and browser_call_webmcp_tool — your agent navigates to a page, discovers tools registered on
document.modelContext, and calls them with JSON input. - MCPBundles dogfoods WebMCP on www.mcpbundles.com — the skills catalog registers
search_skills,get_skill, andget_connect_urlso a browser session can query the marketplace from inside the page, not by guessing DOM selectors. - Works in cloud Chrome (Remote Browser) and Desktop Chrome (Local Browser, WebMCP enabled by default) — same navigate → list → call workflow, no separate bridge extension.
Modern sites are not just HTML anymore. Some already publish structured tools the page understands — search the catalog, fetch an entity, return a connect link. WebMCP is how those tools show up to in-browser agents. Until now, MCPBundles browser automation was excellent at clicks, snapshots, and screenshots — but blind to page-native APIs. That gap is closed.
Two ways to drive a website
Picture a procurement analyst comparing SaaS vendors. The old browser playbook: navigate, snapshot, click "Pricing", re-snapshot, scrape visible text, hope the SPA did not rename the button overnight.
The WebMCP playbook: navigate to a site that registers tools, list what the page exposes, call search_catalog or get_pricing_tier with JSON, read structured results. No invented refs. No fragile CSS.
Both patterns live in the same browser session. DOM automation when you need pixels and clicks; WebMCP when the site already speaks agent.
What shipped in Local and Remote Browser
After you navigate, two new tools join the existing Playwright surface:
- List —
browser_list_webmcp_toolswaits for SPAs to mount (default two seconds), then returns tool names, descriptions, and optional input schemas. - Call —
browser_call_webmcp_toolinvokes by name with a JSON object. Responses are marked untrusted — treat them like any other page-supplied data.
Under the hood the tools prefer Chrome's WebMCP DevTools domain (WebMCP.enable, WebMCP.invokeTool) and fall back to document.modelContext.getTools() / executeTool() when needed. Local Browser launches Chrome with WebMCP enabled through MCPBundles Desktop; Remote Browser uses the same code path against cloud Chrome.
Dogfood: search the skills catalog from inside the browser
MCPBundles registers WebMCP tools on the public skills pages. A realistic agent prompt:
"Open the MCPBundles skills page in Remote Browser, list WebMCP tools, call search_skills for 'postgres', and summarize the top three matches."
The agent navigates, lists three tools (search_skills, get_skill, get_connect_url), calls search with a query string, and gets catalog JSON back — the same data the in-page API would return to a native Chrome agent, without scraping cards out of the DOM.
That is the workflow we want more sites to enable: the page owns the contract, the browser session discovers and executes it.
When to use WebMCP vs snapshots
| Situation | Reach for |
|---|---|
| Login forms, multi-step wizards, visual QA | Snapshots, click, type |
| Site publishes WebMCP tools (search, entity fetch) | List + call WebMCP tools |
| Unknown page, no tool list returned | Snapshots and DOM automation |
| Localhost dev server | Local Browser (direct) or Remote Browser + Desktop tunnel |
WebMCP does not replace accessibility snapshots. It complements them — structured APIs when the site offers them, DOM control when it does not.
Local vs Remote Browser for WebMCP
Local Browser runs Chrome on your machine through MCPBundles Desktop. Localhost dev servers are reachable directly; WebMCP is on by default in the Desktop Chrome launch profile.
Remote Browser runs Chrome in MCPBundles cloud — zero install, ideal for public URLs and long research sessions. WebMCP works the same way; we validated cloud Chrome against the live MCPBundles skills page with list and invoke end to end.
For localhost from the cloud browser, expose your dev port through Desktop (mcpbundles proxy expose 3000) and pass the localhost URL to navigate — the tunnel rewrite is unchanged.
FAQ
What is WebMCP?
WebMCP is a browser-facing pattern where a page registers tools on document.modelContext — names, descriptions, and JSON schemas — so in-browser agents can discover and call them without scraping HTML.
Do I need a browser extension?
No. MCPBundles browser tools talk to Chrome through DevTools Protocol and the page API. Desktop enables WebMCP in Chrome automatically; cloud sessions use the same tool implementations.
Are WebMCP results trusted?
No. Tool responses come from the page you navigated to. Agents should treat them as untrusted input — validate before acting on financial, legal, or security-sensitive data.
Which MCPBundles pages expose WebMCP today?
The public skills catalog on www.mcpbundles.com registers search and connect tools. Product surfaces such as UK Property Intelligence expose pathname-bounded tools on their hosts. More surfaces will follow the same pattern.
Try it from your agent
Enable Local Browser or Remote Browser, connect from Claude Code or Cursor, and ask for a WebMCP workflow on any site that registers page tools — starting with the MCPBundles skills catalog if you want a known-good target.
The browser bundle was already how agents reached localhost, captured screenshots, and walked multi-page research jobs. WebMCP adds the missing lane: structured tools when the website publishes them.