A WebMCP origin trial is the mechanism through which Chrome allows a site to use WebMCP functionality before it becomes a standard feature available by default in the browser. In practice, you request a temporary permit from Google, receive a unique token for your domain, and install it on the page so the browser activates the API only for the registered origin. In this article we explain why this token is needed, how to obtain it, and which mistakes most often prevent WebMCP from working correctly.
What an origin trial in Chrome is
Chrome periodically introduces experimental features that are not yet part of the web's final specification. Instead of enabling them for all users at once, the Chrome team makes them available through origin trials, temporary permissions granted to specific origins that register the domain for testing.
This system serves a dual purpose. On one hand, it lets developers test the functionality in production, with real traffic, and on the other, it gives the Chrome team data on how the API is used before launching it permanently or withdrawing it.
Why WebMCP needs a token
WebMCP is exactly the kind of feature that goes through this testing cycle. Because the API allows web pages to expose capabilities to AI agents, Chrome wants to limit access to sites that have explicitly registered, to avoid unintended activation on domains that haven't been prepared for this behavior.
Without a token, the browser simply ignores the code that calls the WebMCP API, even if the page's implementation is technically correct. For this reason, any WebMCP implementation project must include the step of obtaining the token, not just writing the actual code.
Where to register for the WebMCP origin trial
Registration takes place on the official page developer.chrome.com/origintrials, where Google lists all active trials, including WebMCP, when it is available. A regular Google account is required, with no special requirements such as a paid developer account or organization verification.
On this page you'll find a list of open trials, each with a short description, a link to the technical documentation, and a registration form. Look for the WebMCP entry and first check whether the trial is still active, since Google can end or extend these periods without much advance notice.
The concrete registration steps
The process itself is relatively simple, but it requires attention to detail, especially regarding the exact format of the origin you enter. We recommend following these steps, in this order:
- Sign in with a Google account on the origin trials page.
- Select the WebMCP trial from the list of available ones.
- Enter the exact origin of your site, meaning the protocol, the domain, and, if applicable, the port.
- Choose whether you want coverage for subdomains or only for the origin you entered.
- Generate the token and copy it immediately, since you'll need it in your code.
After generation, the token usually also appears in your Google account, in a list of all the trials you're enrolled in, which is useful when you need to retrieve a token issued earlier.
The difference between origins with and without www
One of the most commonly misunderstood aspects is that, from an origin trial's perspective, exemplu.ro and www.exemplu.ro are two different origins, even though to an ordinary user they look like the same site. A token generated for one variant will not work on the other, no matter how similar the addresses appear.
We recommend checking, before registration, which canonical variant your site actually uses, meaning the one to which traffic is redirected by default. If your site automatically redirects www.exemplu.ro to exemplu.ro, then the correct origin to register is exemplu.ro, not the other way around.
The subdomain option
When generating the token, the origin trials form also offers an option to include subdomains of the entered origin. If you check this option, the token will be valid not only for the main domain but also for any subdomain of it, for example magazin.exemplu.ro or blog.exemplu.ro.
This option is useful when WebMCP is going to be implemented across multiple subdomains of the same organization, but it must be used with discernment. A token with subdomains enabled extends the surface on which the functionality becomes available, even if some subdomains aren't yet ready in terms of content exposed to AI agents.
The token's expiration date
Every origin trial token has an expiration date clearly displayed at the time of generation, and this usually corresponds to the trial's official period as set by Chrome. It's important to note this date somewhere visible, not just in the site's configuration file, where it risks going unnoticed.
After the expiration date, the browser simply stops recognizing the token as valid, and WebMCP functionality disappears from the page without any error message visible to the end user. If your implementation is critical for AI agent workflows, integrating a WebMCP maintenance and monitoring service can prevent this kind of silent interruption.
Delivery via meta tag on the page
The first method for installing the token is to add a meta element in the head section of the HTML page, with the http-equiv attribute set to the appropriate value for the tested origin and the content equal to the received token. This method is direct and doesn't require access to server configuration.
The downside of this approach is that every page that needs WebMCP functionality must separately include this meta tag, which can become cumbersome on large sites with multiple templates. In addition, if a page is served from a static cache, a recently added token may not actually reach the version served to users.
Delivery via HTTP header
The second method consists of sending the token through a dedicated HTTP header, set at the level of the server's response for every relevant request. This approach has the advantage of being configurable centrally, at the web server or application level, without modifying every individual HTML template.
Header-based delivery is usually preferred on more complex infrastructures, where a common configuration layer already exists for all pages, such as a reverse proxy or an application middleware. However, any infrastructure change must be carefully tested to confirm that the header reaches the browser unaltered.
Which method to choose
There's no universally valid answer for all sites, the choice depends on the existing technical architecture and on who controls the code versus the infrastructure. Both methods are officially supported by Chrome and produce exactly the same effect: activating the functionality for that origin.
As a practical rule, if your team directly controls the HTML templates, the meta tag is faster to implement. If, instead, you already have a header configuration layer covering the entire site, the HTTP header avoids the risk of forgetting the token on some newly created page.
The common mistake: wrong origin
The most frequent problem is generating the token for an origin that doesn't exactly match the one actually served to users. This happens when the site runs on a staging environment during testing, and the generated token remains tied to that test domain instead of the production domain.
Another variant of the same mistake is confusion between http and https, since the protocol is part of the origin used when generating the token. If your site recently switched to https but the token was generated earlier, for the http variant, it will not be recognized as valid.
The common mistake: token cut off by cache
The second common source of problems occurs when the site uses a caching mechanism, either at the server level or through a CDN, and the version served to users is an older copy of the page, generated before the token was introduced. In this case, checking the source code in the editor may look correct, but the end user still receives the page without the token.
We recommend explicitly invalidating the cache after any change related to the WebMCP origin trial, both for the HTML page and for any caching rules applied to HTTP headers. It's also useful to check the server's response directly, not just the source displayed in the browser, since some developer tools can hide subtle differences introduced by caching.
The common mistake: untracked expiration
The third common mistake isn't a matter of technical configuration but of internal process, namely the lack of a clear owner responsible for tracking the token's expiration date. Many teams install the token correctly at launch but completely forget about it in the following months, until the functionality suddenly disappears.
The situation is made worse by the fact that expiration doesn't produce a visible error in the browser console for the average user, it simply silently disables the WebMCP API. A simple periodic verification process, similar to monitoring an SSL certificate, can prevent this type of incident.
How to check whether the token is working
The most direct verification method is inspecting the page's source code or the response headers to confirm that the token appears exactly as it was generated, without extra spaces or truncated characters. Chrome's developer tools allow you to view the complete headers for each request.
Beyond manual verification, a dedicated tool can automatically confirm whether your site's WebMCP implementation is correctly configured, including the presence and validity of the token. You can use the WebMCP validator to quickly test a page and get a clear report on any issues.
When it's worth asking for specialized help
If your technical team hasn't worked with origin trials before, the process can seem unclear, especially regarding the differences between origins, subdomains, and delivery methods. In these situations, a dedicated technical audit can quickly identify exactly where the activation of the functionality is getting blocked.
For sites with complex architecture, multiple subdomains, or several layers of caching, we recommend a WebMCP origin trial service that covers both token registration and verification of correct delivery across all relevant pages. It's better to invest a little time in verification now than to discover months later that the functionality was never actually active.
Conclusion
Correctly obtaining and installing the token is not an optional step in a WebMCP implementation, it's a mandatory technical condition for the browser to activate the functionality. Attention to detail, the exact origin, the chosen delivery method, and tracking the expiration date make the difference between a working implementation and one that suddenly stops, with no visible explanation.
