- What we shipped
- How little it actually took
- The one gotcha that matters: navigator vs document
- Joining the origin trial
- What an agent actually does with the tool
- What we deliberately did not do
- What we would tell you to do now
- FAQs
- The point of doing it first
We just published a page on agent-ready websites and a primer on what WebMCP is. Talking about it is cheap. So we did the obvious thing an AI automation agency should do: we made our own site agent-callable.
As of this writing, cloudnsite.com exposes a real WebMCP tool, submit_contact_request, that an in-browser AI agent in a supporting Chrome can discover and call. This is the build log: what it took, the one thing that tripped us up, and the honest read on what is worth doing today.
---
What we shipped
We exposed exactly one action to start: submitting a contact request. An agent acting for a user can now call submit_contact_request with a name, email, and message, and the request flows into our normal lead pipeline. We picked contact first on purpose. It is a high-intent action with a clean, well-defined input, which is exactly the kind of thing a tool should be.
We verified it live, not in theory. Calling navigator.modelContext.getTools() on the page returns the tool with its schema, which means any compliant agent on the page can see it and invoke it.
---
How little it actually took
This is the part that surprised even us. The whole implementation is one small module plus a single meta tag.
- One tool registration. A
registerToolcall with a name, a natural language description, a JSON schema for the inputs, and anexecutefunction. Theexecutefunction reuses the exact same backend endpoint our human contact form already posts to, so an agent submits precisely what a person would, with the same validation, the same durable capture, and the same lead routing. There is no separate code path to maintain. - Feature detection. The registration only runs if the browser actually supports WebMCP. In every other browser it is a complete no-op, so there was zero risk to the live site.
- One meta tag. The origin-trial token, which we will get to below.
That is the entire footprint. No new server, no new infrastructure, no new dependency. It deploys with the static site we already had.
---
The one gotcha that matters: navigator vs document
Here is the practical detail you will not get from a summary article. The WebMCP specification and its explainer document the API on document.modelContext. The Chrome build we tested on exposes it on navigator.modelContext. Same methods, different object.
This is normal for a feature still in preview. The lesson is to feature-detect both rather than hard-code one. Our registration checks document.modelContext first, then navigator.modelContext, and uses whichever exists. When we ran it against a live Chrome that only had the navigator form, it found it and registered cleanly. If we had bet on document alone, the tool would have silently failed to register.
If you take one thing from this post, take that: while the standard is in preview, code defensively against where the API lives.
---
Joining the origin trial
For the API to be available in a normal Chrome, rather than only behind a developer flag, you join the WebMCP origin trial. You register your origin in Chrome's origin-trial console, receive a token, and drop it into your page head as a single meta tag. It is free.
Two practical notes. The token is scoped to your exact origin, so register the canonical one you actually serve from. And origin trials are time-boxed, so you will get a renewal reminder before the trial window closes. Renewing is the same short form. That is the only recurring maintenance.
---
What an agent actually does with the tool
The flow is clean and worth understanding because it is the whole value proposition. An agent on the page calls getTools to discover what is available and reads each tool's input schema. When it wants to act, it calls the tool with structured arguments that match the schema. The browser mediates the call, our execute runs, and a structured result goes back.
Compare that to the status quo, where an agent takes a screenshot, guesses where to click, and breaks when a modal appears. WebMCP inverts it: the site tells the agent what is possible instead of the agent reverse-engineering the interface. That is more reliable and far less brittle, which is the entire reason the standard exists.
---
What we deliberately did not do
We did not expose booking yet. Booking depends on real-time availability, so the tool design is more involved, and we would rather ship one clean tool than two half-built ones. We will add it deliberately.
We are also not pretending this is a traffic channel today. WebMCP is a W3C Community Group draft in browser preview and origin trial. The population of agents that will actually call this tool right now is small. We built it because we are an agency that sells this, so a working reference implementation is worth more to us than the immediate call volume. For most businesses, that calculus is different, and we say so plainly.
---
What we would tell you to do now
Prepare, do not panic-build. The highest-value work is making your key actions clean, structured, and easy to expose: clear inputs, predictable outputs, real form semantics. That work pays off immediately for accessibility and AI-assistant discovery, and it means you can turn WebMCP on in days when native browser support broadens, instead of rebuilding a site that was never designed for agents.
If you want one action exposed as a proof of concept, it is genuinely a small job. If you want a straight read on whether it is worth it for your specific site, that is a conversation worth having before you spend a dollar.
---
FAQs
Is WebMCP hard to implement? No. A single tool is a small module plus an origin-trial meta tag, and it can reuse the backend endpoint your existing forms already use. The hard part is not the API, it is having clean, well-defined actions worth exposing.
Does adding WebMCP risk breaking my site? Not if you feature-detect. The registration should only run when the browser supports WebMCP and otherwise do nothing. Implemented that way, it is invisible and inert everywhere else.
Which object is the WebMCP API on, navigator or document? The specification documents document.modelContext, but some Chrome builds expose it on navigator.modelContext. Because the standard is still in preview, check both and use whichever is present.
Do I need the origin trial to use WebMCP? To have the API available in a normal Chrome without a developer flag, yes. You register your origin, get a free token, and add it as a meta tag. The token is scoped to your origin and the trial is time-limited, so plan to renew.
Should my business implement WebMCP right now? For most businesses, prepare rather than rush, because the standard is in preview and few agents call WebMCP tools yet. The exception is teams for whom a live reference implementation has direct value, such as agencies and software vendors building for the agentic web.
---
Sources
- W3C Web Machine Learning Community Group, WebMCP specification (Draft Community Group Report) (2026): the tool registration model, input schemas, and the
document.modelContextAPI surface, created by engineers at Google and Microsoft. - Chrome for Developers, Join the WebMCP origin trial (2026): the origin-trial process, the
navigator.modelContextAPI, and the discover-and-call flow. - Anthropic, Model Context Protocol: the open protocol whose tool model WebMCP brings into the browser.
---
The point of doing it first
The agentic web is going to reward sites that are usable by agents, not just readable by them. We would rather learn that on our own site, with our own lead pipeline, before we recommend it to a client. Now we have.
If you want your site to be one of the first an agent can actually use, that is what we do. See agent-ready websites, or book a free 30-minute call and we will give you a straight read on what is worth building now.