Which AI agents support WebMCP today — natively, via snippet, or not at all. Chrome auto-browse, Comet, Safari/WebKit, ChatGPT, and what to ship for each.
WebMCP coverage tends to blur two different questions: whether the standard is winning, and whether your tools are reachable by the agents that visit your site. This matrix answers the second question. It reflects verified status as of June 11, 2026 — the day WebKit formally resolved its position as "oppose" — and gets updated as agents change.
| Agent surface | Type | Invokes WebMCP? | What reaches it |
|---|---|---|---|
| Chrome auto-browse (Gemini)The highest-volume agent surface. Does not invoke WebMCP tools. | OS-level browser agent | No — drives the DOM | Clean, accessible DOM (forms, labels, no JS-gating) |
| Perplexity CometPart of the current opt-in invoker set. | Agentic browser | Yes — invokes registered tools | WebMCP tools via snippet or native registration |
| Chromium (Chrome/Edge) native APIEdited by Google and Microsoft engineers; not shipped to mainstream users. | Browser engine | Flag + origin trial only | navigator.modelContext behind a flag — not default-on |
| Safari / WebKitFormal opposition citing API design, privacy, security, portability, duplication. | Browser engine | No — position: oppose (June 2026) | Snippet-based tools unaffected; DOM path works |
| ChatGPT browsing / agentsServer-side fetchers never see browser APIs at all. | Server-side + browser agents | Not via browser API | Readable content, llms.txt, structured data; custom agents can call tool endpoints |
| Browser extensions & custom agentsSmall but real invoker set; grows with the ecosystem. | Opt-in tooling | Yes — where built against the draft | WebMCP tools via snippet registration |
Two facts carry most of the weight. First, the biggest agent surface — Chrome auto-browse — never calls WebMCP, so your DOM quality decides whether those transactions complete. Second, the agents that do invoke WebMCP tools reach them just as well through a script snippet as through a native browser API, which means WebKit's opposition changes approximately nothing about what you should ship.
The practical stack is the same one the WebMCP explainer lands on: fix the DOM first, ship llms.txt so agents know what your site offers, then register tools via a snippet for the invoker set that exists today. If you expose tools, run them through a safety pass — Chrome has published guidance on how WebMCP manifests can be abused, covered in our WebMCP security guide.
This page is maintained by hand against primary sources: browser standards-position trackers, agent vendor documentation, and what we observe invoking tools across sites running the Crawlytics snippet. When an agent ships or drops WebMCP support, the matrix row and the last-updated date change. If you spot a stale row, tell us and we will verify and fix it.
As of June 2026, WebMCP invocation is limited to an opt-in set: Perplexity Comet, some browser extensions, and custom agents built against the draft API. Chromium browsers expose navigator.modelContext behind a flag and origin trial, so nothing invokes tools for mainstream users by default yet. Chrome auto-browse, the highest-volume agent surface, drives the page DOM and does not call WebMCP tools.
No, and its engine vendor has formally opposed the proposal. WebKit resolved its standards position on WebMCP as "oppose" in June 2026, citing concerns including API design, privacy, security, portability, and duplication of existing web platform capability. That makes near-term native Safari support unlikely — which matters less than it sounds, because most agent traffic does not run in Safari.
No. Chrome auto-browse operates websites the way a person does: it reads the rendered page and drives the DOM — forms, buttons, navigation. It does not call WebMCP tools. If auto-browse traffic is what you are preparing for, a clean accessible DOM is the requirement; WebMCP is a separate, optional efficiency layer for the agents that do invoke tools.
Yes. A script-snippet implementation registers your tools in page JavaScript and handles invocation through your own endpoint, so it works in any browser and for any API-driven agent, independent of whether the engine ships navigator.modelContext. This is how the Crawlytics WebMCP snippet works — browser-engine politics do not affect it.
No. Standards positions will take years to resolve, and the agents that matter for commerce are either API-driven or Chromium-based. Implementing via a snippet today costs little, works for the current invoker set, and leaves you ready the moment any browser turns the native API on. Waiting buys nothing except a later start.
This page is part of Crawlytics.app. View all pages: llms.txt · llms-full.txt