WebMCP with ChatGPT, Claude, and Gemini: Does It Actually Work?

You've added WebMCP tools to your website. Your pricing page has a callable getPlans function. Your feature directory is searchable by agents. Everything works in Chrome DevTools.

But then someone asks the obvious question: can ChatGPT actually call those tools? What about Claude? Gemini?

The short answer is that it depends on how each platform accesses the browser. WebMCP is a browser-native API, which means the AI needs to be running inside a browser tab to see your tools. Some platforms are closer to that than others, and the gap is closing faster than most people realize.

This article breaks down the current compatibility picture for each major AI platform, explains why the browser requirement matters, and gives you a practical strategy so your tools are ready regardless of which platform catches up first.

How AI platforms connect to WebMCP

The browser requirement

Here's the thing most people miss about WebMCP: it's not an API you call from a server. It's a JavaScript API that runs inside a browser tab through navigator.modelContext.

That distinction changes everything.

When you register a WebMCP tool on your website, it only exists in the browser's runtime. There's no URL an external service can hit. There's no webhook. The tool lives in the DOM environment of your page, and an AI agent has to be present in that same browser context to discover and call it.

This is different from how most AI integrations work today. ChatGPT plugins, for example, call REST APIs on your server. MCP servers expose tools through a backend protocol. Those work without a browser entirely.

WebMCP flipped the model. Instead of your server talking to the AI, your webpage talks to whatever AI agent is operating the browser. The agent lands on your page, the browser exposes your registered tools through the navigator.modelContext API, and the agent calls them.

Browser agents vs chat agents

This creates two categories of AI that matter for compatibility.

Browser agents run inside an actual browser. They navigate pages, read content, and interact with the DOM. These agents can see WebMCP tools natively because they're operating in the same JavaScript environment where the tools are registered.

Chat agents are what most people use day-to-day. You type a message in ChatGPT or Claude, and the AI responds. When these agents "browse the web," they're typically using a headless browser or API proxy in the background. Whether that proxy supports WebMCP depends on the platform's implementation.

The trend I keep watching is convergence. Every major AI platform is adding deeper browser capabilities. ChatGPT has browsing mode. Claude has computer use. Gemini is baked into Chrome itself. They're all moving toward the same destination: AI agents that can operate a browser the way you do.

And when they get there, your WebMCP tools will be waiting.

Platform-by-platform compatibility

Google Gemini and Chrome AI

Google has the clearest path to WebMCP support, and the reason is straightforward: Google co-authored the specification.

Chrome 146 Canary already ships with navigator.modelContext behind a flag. When you enable it, the browser natively understands WebMCP tool registrations on any page you visit. Gemini, as Google's AI, is being built to run directly inside Chrome.

The integration path looks something like this: you visit a website in Chrome, the page registers its WebMCP tools, and Gemini (either through the browser sidebar or an embedded agent) can discover and call those tools without any extension or bridge layer.

I spent a few hours testing this in Canary last month. The tool discovery was immediate. I had a test page with three registered tools, and the browser's model context API picked them up on page load. The consent flow prompted me before the agent could call anything, which is how the security model is supposed to work.

Google also has the distribution advantage. Chrome holds roughly 65% of desktop browser market share. When WebMCP moves from Canary to stable, it will ship to over a billion browsers. That's not a niche protocol anymore.

Microsoft is co-authoring the spec too, which means Edge will likely follow closely behind Chrome. Between the two, you're looking at something like 70% of desktop browsers.

OpenAI ChatGPT

ChatGPT's relationship with WebMCP is more complicated.

When ChatGPT browses the web today, it uses a server-side browser that fetches pages and extracts content. That browsing mode wasn't built with WebMCP in mind. It renders pages enough to read text and follow links, but it's unclear whether it executes the JavaScript needed to register WebMCP tools.

Then there's the GPT Actions ecosystem. OpenAI already lets developers connect tools to ChatGPT through custom actions, which are essentially OpenAPI schema definitions pointing at REST endpoints. This is a server-to-server model, and it works well for backend APIs.

WebMCP is a different paradigm. Instead of your server exposing an API for ChatGPT to call, your webpage exposes tools for a browser-based agent to call. These aren't competing approaches; they solve different problems. GPT Actions handle backend integrations. WebMCP handles frontend, browser-context interactions.

The interesting signal is ChatGPT's Operator feature and the broader push toward agentic browsing. As OpenAI builds agents that can navigate and interact with websites in a real browser, those agents will naturally encounter WebMCP tools. The question isn't whether OpenAI will support it, but when their browser agent runtime will execute navigator.modelContext discovery.

My guess: once Chrome ships WebMCP in stable and websites start registering tools at scale, OpenAI will have strong incentive to support it. Their browser agents will need to keep up with what Gemini can do natively.

Anthropic Claude

Claude's path to WebMCP runs through two channels.

First, there's Claude's computer use capability. Claude can control a desktop and browser through screenshots and mouse/keyboard actions. In this mode, Claude is operating a real browser, which means pages with WebMCP tools could theoretically expose them. The catch is that computer use currently works through screen reading and pixel-level interaction, not through JavaScript API access. Claude sees what's on screen but doesn't directly query navigator.modelContext.

Second, there's the MCP ecosystem. Anthropic built the Model Context Protocol (the server-side version, not the browser one) and has a large ecosystem of MCP servers. A browser-bridge MCP server could connect Claude to WebMCP tools on a page. The community is already building these bridges.

The most direct route might be Claude's presence in browser extensions. If Claude runs inside a Chrome extension with content script access, it could read navigator.modelContext from any page the user visits. That would give Claude the same WebMCP access as a native browser agent.

Anthropic hasn't announced specific WebMCP integration plans, but the building blocks are all there. Claude already understands tool schemas through MCP and operates real browsers through computer use. It runs in browser contexts through extensions too. Connecting those pieces to WebMCP is more of an engineering task than a conceptual leap.

Open-source agents

The open-source agent ecosystem might actually be the first to fully support WebMCP in practice.

Frameworks like browser-use, LaVague, and Agent-E already automate real browsers using Playwright or Puppeteer under the hood. These agents run in full browser environments where navigator.modelContext is available. Adding WebMCP tool discovery to these frameworks is a relatively small change because they already have JavaScript execution access in the page.

Some projects are already experimenting with this. If you run a browser-use agent in Chrome Canary with the WebMCP flag enabled, it can call navigator.modelContext.tools and get back the list of registered tools on any page. The agent still needs logic to decide when and how to use those tools, but the plumbing works.

The advantage of open-source agents is speed. There's no product roadmap committee or quarterly planning cycle. Someone sees an opportunity, writes a PR, and ships it. I'd expect WebMCP support in the major open-source frameworks before any of the commercial platforms fully integrate it.

The downside is reach. Most people don't run open-source browser agents. The real inflection point comes when ChatGPT, Claude, or Gemini support WebMCP natively, because that's where the user base is.

What this means for website owners

Implement now, benefit later

If you're waiting for universal platform support before implementing WebMCP, you're thinking about it backwards.

WebMCP tools use progressive enhancement. You add them to your existing pages, and they sit there quietly until an agent comes along that understands them. Browsers that don't support WebMCP ignore the navigator.modelContext calls entirely. Nothing breaks. Your page works exactly as it did before.

But here's what you gain by implementing early: when platforms do add support, your tools are already in place. You don't have to scramble to build and test them while your competitors are doing the same thing. You've already worked through the schema design, the edge cases, and the security model.

There's also a discoverability angle. As WebMCP adoption grows, AI agents will start preferring websites that expose structured tools over websites that require screen scraping. If you're the only competitor in your space with WebMCP tools, you get the agent's recommendation by default.

I think of it like mobile-responsive design in 2010. The people who built responsive sites before mobile traffic exploded didn't have to retrofit anything. They were just ready.

Maximizing cross-platform compatibility

Since different platforms will access your tools through different mechanisms, write your tools to be as portable as possible.

Start with tool descriptions. Every platform that consumes WebMCP tools will rely on the description field to understand what a tool does and when to use it. Vague descriptions like "get data" won't cut it. Write descriptions as if you're explaining the tool to a new developer on their first day. Be specific about what it returns and when someone would need it.

Use standard JSON schema patterns for your parameters. Stick to basic types (string, number, boolean, enum) and avoid complex nested objects. The more exotic your schema, the more likely some agent runtime will choke on it.

Keep your handlers defensive. Validate inputs, return clear error messages, and handle edge cases. You don't control which agent is calling your tool or what parameters it sends. Treat every invocation like an untrusted API request.

And test with multiple runtimes. Try your tools in Chrome Canary's native implementation. Test with the @mcp-b/global polyfill. If you can, test with an open-source browser agent. Each runtime has slightly different behavior, and catching those differences early saves you headaches later.

Frequently asked questions

Can ChatGPT use WebMCP tools today?

Not directly. ChatGPT's current browsing mode uses a server-side renderer that doesn't execute WebMCP tool registration JavaScript. As OpenAI expands its agentic browsing capabilities (like the Operator feature), WebMCP support will likely follow. For now, ChatGPT interacts with websites through its own browsing pipeline and GPT Actions for structured tool calls.

Which AI platform will support WebMCP first?

Google Gemini is the most likely first mover. Google co-authored the WebMCP spec, Chrome 146 Canary already includes the navigator.modelContext API, and Gemini is being built to run natively inside Chrome. Microsoft's Copilot in Edge is a close second, since Microsoft is also co-authoring the specification.

Should I wait for full platform support before implementing WebMCP?

No. WebMCP uses progressive enhancement, meaning your tools only activate when a compatible agent visits your page. Nothing breaks for regular users or unsupported browsers. Implementing now gives you a head start on schema design, security review, and testing. When platforms add support, your tools will be ready immediately.

Does WebMCP replace ChatGPT plugins or GPT Actions?

They solve different problems. GPT Actions connect ChatGPT to your backend API through server-to-server calls. WebMCP connects any browser-based agent to tools on your frontend through the browser's JavaScript runtime. A SaaS product might use GPT Actions for deep backend integration and WebMCP for marketing-site tool exposure. They complement each other.

Will WebMCP work in Firefox and Safari?

The specification is being developed through W3C's Web Machine Learning Community Group, so it's designed as a cross-browser standard. Google and Microsoft are the current implementers. Mozilla and Apple haven't announced support yet, but the @mcp-b/global polyfill makes WebMCP available in any browser today. Native support in Firefox and Safari will depend on those teams' prioritization.