BTradeTech · WebMCP
WebMCP Browser Support
Support depends on the environment. This table separates official API documentation, framework helpers and unverified assumptions.
Browser support reviewed 17 September 2026
This page records verified documentation status, not a promise that every browser, channel or site can execute every tool. Runtime support depends on the browser build, permissions, page lifecycle, schema and application authorization.
| Environment or surface | Verified status | Evidence and limitation |
|---|---|---|
| Chrome documentation / document.modelContext | Officially documented draft / preview surface | Imperative API; not a universal stable-browser guarantee. |
| Chrome browser runtime | Not runtime verified by this site | Requires a controlled browser test for the target page. |
| Edge and other browsers | No blanket support claim | Check the current browser channel and official release notes before rollout. |
| Declarative forms | Officially documented API path | Declarative API; framework support still needs app testing. |
| React / Next.js / WordPress / Shopify | Integration guidance only | No framework-specific browser support is inferred. |
How to verify your own stack
Load the real page in the intended browser channel, inspect registered tools, invoke a harmless read-only action, then test validation, errors, navigation cleanup and confirmation for consequential actions. Until that test exists, label the result static or suggested.
What this support review can verify
This reference can verify that the public guidance names an API surface, that the BTradeTech scanner can find static references, and that the page explains the limits of those signals. It can also record the review date, the source used, the intended browser environment and the test status. Those are useful facts for planning, but they are deliberately narrower than a claim that every visitor can use every tool.
Static evidence versus runtime support
Static evidence includes HTML, scripts, form attributes, semantic labels and deployment metadata. It can show that a page contains document.modelContext, a registerTool() call or declarative form attributes. It cannot prove that hydration completed, registration happened once, the tool was visible to the agent, the input was accepted, the authenticated user was authorized, or the server completed the requested action. Runtime support requires a controlled browser test on the real page, browser channel, account state and application data.
How teams should verify a browser claim
- Record the browser channel, operating system, URL, build and review date.
- Load the production-like page and confirm that registration occurs after the page lifecycle is ready.
- Inspect the available tool name, description, schema and confirmation behavior.
- Run a harmless read-only task with valid and invalid input, then test navigation cleanup.
- Test a consequential workflow separately and verify that the final commit remains behind visible human confirmation.
Framework, deployment and fallback notes
React and Next.js need client-lifecycle and SSR boundaries. WordPress needs theme, plugin, nonce and cache checks. Shopify needs guest, customer, inventory, currency and checkout checks. A reverse proxy, content-security policy, cache layer or consent gate can change what reaches the browser. Every implementation should retain a usable human form or button when the WebMCP surface is absent. Use the What Is WebMCP? guide, Simulator, Autopilot, Generator, Validator and Implementation Service to move from documentation to evidence.