WebMCP Updates

WebMCP Updates: what changed in this review

This page is a dated change record for the WebMCP guidance used by BTradeTech. The current review prioritises the documented browser surface, labels implementation evidence separately from optional discovery conventions, and avoids describing a draft or preview capability as universal stable-browser support. The reviewed date is 17 September 2026; recheck the official sources before a production rollout.

Current imperative guidance

The current implementation guidance centres on document.modelContext and registerTool(). A useful registration has a stable name, clear description, strict input schema and an execute handler connected to existing application logic. Feature detection and a human-facing fallback remain important because a visitor may use a browser without the relevant surface. References to navigator.modelContext are treated only as legacy compatibility signals.

Declarative forms are a separate path

The documented declarative route uses form-level annotations such as toolname, tooldescription and parameter descriptions. It can fit a clear existing form, but it does not remove normal label, required-field, consent, nonce, authorization or server validation requirements. Teams should choose the path that expresses the real workflow and test the active framework, theme, plugins and caching configuration.

Safety and confirmation updates

Read-only search, product lookup, support knowledge and invoice listing can be good first candidates, subject to authorization. Quote preparation, cart preparation, booking, MFA reset, checkout, payment and order submission need more careful boundaries. A consequential action should explain what will happen, show the final values and wait for explicit human confirmation before the commit. Tool annotations help communicate intent; they do not replace server-side controls.

What the BTradeTech tools report

The Checker reports static evidence from public HTML and same-origin scripts. Autopilot discovers and prioritises candidate actions. The Simulator maps a natural-language task to a detected or suggested action. The Generator creates a scaffold, and the Validator explains static errors. Optional llms.txt, manifests and schema.org actions are never counted as official WebMCP requirements.

Browser verification status

Static source evidence cannot prove registration after hydration, successful execution, permissions, application authorization or safe confirmation. This deployment therefore reports runtime as NOT RUN unless a controlled browser is actually configured. The browser-support page records this limitation and separates official documentation from framework guidance and unverified assumptions.

How teams should handle future changes

Record the source URL, reviewed date, API path, browser channel, test page, tool names and expected confirmation behavior in the implementation ticket. Re-run static checks after dependency or theme changes, then run a controlled browser test for harmless read-only actions and separate tests for errors, navigation cleanup and consequential confirmation. For a managed rollout, use the Implementation Service.

Update FAQ

Does a new browser mention automatically make a site ready? No. Does llms.txt implement WebMCP? No. Does a high static score prove a successful task? No. The reliable status vocabulary remains existing or detected evidence, suggested opportunity, runtime verified test, and not run.

Release checklist for a changing API

When a browser preview, documentation page or framework adapter changes, compare the new behavior with a small written contract. Check registration, duplicate-name handling, input rejection, navigation cleanup, result rendering and the ordinary human fallback. Keep the reviewed date beside the source link and describe the browser channel used. This makes an update useful to implementers: it explains what changed, what was tested, and what still cannot be claimed. A new syntax example should be copied into a non-production page first, with harmless read-only data and no credentials in client code.

Keep the cluster current

Use the Validator after code or dependency changes, revisit the browser-support reference, and request an implementation review when a tool crosses from discovery into a consequential workflow.