A WebMCP origin trial is the mechanism through which Google Chrome allows an origin to use the WebMCP API before it becomes a standard feature, available by default in the browser. Without a valid token, the API simply isn't available in stable Chrome, and none of the tools you define on the page ever reach the conversational agent trying to call them. In practice, your entire WebMCP setup can be correctly built from a code standpoint and still not work for visitors, if the token is missing, expired, or fails to reach the browser as intended. Our service checks exactly this chain and provides technical proof of its status.
Registering the WebMCP origin trial token
The token is obtained from the Chrome developer console, for an exact origin (domain, with or without subdomain, plus protocol) and for a set period of time. We check whether the registration was made for the correct origin, whether the protocol used matches the live site, and whether the subdomain inclusion setting reflects how your site is actually structured. A registration made for the root domain, when the relevant content actually lives on a subdomain, is a common cause of silent failure, with no visible error for the technical team.
The two ways to deliver the token
Chrome accepts the token in two forms, and they are not interchangeable in terms of final outcome, even though both can be technically valid:
- A meta tag placed in the head section of every page that needs the API.
- An HTTP header sent by the server with every relevant response, often preferred for dynamically generated sites or ones served through multiple infrastructure layers.
We check which of the two methods is actually in use, whether it's consistent across all pages that need it, and whether an old and a new version of the token might coexist, a situation that can cause inconsistent behavior between pages.
Checking the origin: with and without www, and the subdomain option
From a web origin standpoint, example.com and www.example.com are different origins. A token registered for one variant isn't automatically valid for the other, unless the subdomain option was checked at registration and correctly covers the situation. We check which variant is actually served to visitors (including redirects from one variant to the other) and confirm whether the token covers exactly that variant. It's a small detail, but enough to keep the entire feature from ever activating, without any error appearing visibly in the interface.
Expiration date and the interrupted delivery trap
Every token has an expiration date, and once that point passes, the browser ignores it completely, as if it never existed. We check the exact expiration date and flag the time remaining until renewal. Beyond expiration, there's a less obvious trap: the token can be correct, valid, and not yet expired, but never actually reach the browser, because it's stripped along the way. This often happens due to static caching, a CDN configured to drop certain HTTP headers, or an optimization module that "cleans up" the page's head section and removes tags mistakenly considered redundant. The end result looks identical to a missing token from the visitor's perspective: the API isn't available, and the agent sees no tools at all.
How we confirm the origin and expiration of the token
Our validator doesn't just check for the presence of a tag or a header. It decodes the token's binary content, extracts the registered origin, the feature covered, and the expiration date, then compares them against the actual state of the site as delivered to the browser. This means we don't stop at "the token appears to be there," but can state exactly which origin is covered, until when it's valid, and whether what reaches the client matches what was registered.
As part of the service, we specifically check:
- Whether the token is present on all relevant pages, not just the homepage.
- Whether the origin decoded from the token exactly matches the origin being served (protocol, domain, with or without www).
- Whether the expiration date leaves a reasonable margin before renewal is needed.
- Whether a caching layer, CDN, or optimization tool strips the token from the final response sent to the browser.
For reproducible, explainable results, we use the same method described in our verification methodology, and any client can reproduce the steps independently, using their own tools.
Token renewal, and why we recommend monitoring
An origin trial isn't a one-time, permanent setup. The token needs periodic renewal, and if this step is missed, WebMCP functionality disappears without any visible notice to the team managing the site, much like when delivery gets blocked by caching. For this reason, we recommend ongoing monitoring, not just a one-time check at launch. A single check confirms the status at that moment, it doesn't guarantee the status three months later, especially if infrastructure changes, hosting provider switches, or optimization module updates occur in the meantime. Details about this continuous monitoring service can be found on our dedicated WebMCP maintenance and monitoring page.
Quick check, then a focused conversation
If you'd like a first look, with no commitment, you can run our validator for free on your domain and immediately see whether the token is present and appears valid. For a full confirmation, including decoding of the origin and expiration and identifying any causes of interrupted delivery, you can reach us through our contact page, and we'll work out together what steps are needed for your site's specific situation.