Browser Compatibility

Aigentably tools work in all major browsers via native support or automatic polyfill.

How compatibility works

The Aigentably snippet checks for document.modelContext on load. If it's not available natively, it loads the WebMCP polyfill before registering your tools.

The polyfill is served from the same domain as the snippet itself. That matters if your site sends a Content-Security-Policy: allowing https://aigentably.com in script-src covers both, with no second origin to add.

// Simplified snippet logic
if (!document.modelContext) {
  await loadPolyfill() // loads WebMCP polyfill
}
// Register tools...

This means you don't need to do anything. Compatibility is handled automatically.

Browser support

AI agent compatibility

AI agents that support WebMCP natively query document.modelContext.getTools() directly. Agents that don't yet support WebMCP will not call your tools, but as the standard matures, more agents will adopt it.

As of August 2026, no mainstream AI agent (Claude, ChatGPT, Gemini, Perplexity) calls WebMCP tools in production yet. Google's Chrome Model Context Tool Inspector extension already demonstrates tool invocation via Gemini for testing, and the mcp-b browser extension bridges tool calls for developers who opt in. Native agent adoption is expected to follow as the origin trial matures.

Polyfill loading

The polyfill loads automatically from your own Aigentably domain (falling back to a public CDN only if that fails). If it fails entirely, the snippet logs a warning and continues. Native WebMCP still functions where available.

Checking your own tools in Chrome

Chrome ships a WebMCP panel in DevTools, and Google publishes a companion Model Context Tool Inspector extension, for inspecting registered tools directly in the browser. Both read from a separate, experimental surface (navigator.modelContextTesting) rather than the production API (document.modelContext) that real agents use — Aigentably's snippet already keeps this mirrored automatically, so what you register shows up there too.

That surface is off by default in Chrome itself. To see your tools in either tool, enable chrome://flags/#enable-webmcp-testing in your own browser first — this is a setting on the browser doing the inspecting, not something a site configures. Your dashboard's Tool Registration Check works without any flag and is the check that matters for real agent traffic; the DevTools panel and the Inspector extension are optional, for browsing your own tools by hand.

If you'd rather not offer that one-click convenience for a tool that does something consequential (a discount code, a cart change), turn it off per site under your site's dashboard page → "Visible in Chrome's WebMCP DevTools". It changes nothing about what real agents can call — that goes through the same registry either way — it only removes the manual-invoke button from Chrome's own inspection tools.

Origin-keying: WebMCP needs it, and most sites don't have it by default

Chrome throws a SecurityError on any access to document.modelContext unless the page is in an origin-keyed agent cluster. Two separate things can leave a page out of one, and they produce the identical error message:

1. The page sets document.domain — a legacy technique some sites still use to relax same-origin checks across subdomains, so a parent page and a subdomain iframe can reach into each other freely. Doing this takes a page out of an origin-keyed agent cluster for good, even if it sets document.domain to the value it already had.
2. The page never opts in at all. Absent an explicit Origin-Agent-Cluster: ?1 response header, Chrome's default is not origin-keyed — no document.domain involved anywhere. This is the more common case in practice, since most sites have never had a reason to send that header, and it's why the error can show up with no offending line of JavaScript to find.

Neither is something Aigentably does on your behalf — check your own page's source (or any third-party script or widget you've embedded, e.g. a legacy analytics tag or an old cross-subdomain SSO snippet) for a line like document.domain = "example.com" to rule out the first cause; check your server's response headers for Origin-Agent-Cluster to check the second. If neither is present, sending Origin-Agent-Cluster: ?1 on your own responses is the fix — it's what we do on aigentably.com itself.

If you find an actual document.domain assignment, no WebMCP tools will register on that page — native or polyfilled — for as long as it's set. Since document.domain is a deprecated pattern Chrome is phasing out on its own regardless, removing it is the fix rather than something to route around.

You don't need to watch for the document.domain case yourself: the snippet detects it and reports it to us automatically, so we can flag it to you if it ever comes up.