Right now, a growing number of people don't browse the web by clicking through pages themselves — they ask an AI agent to do it for them: "Find me 3 fractional CMOs who understand AI search, and ask each for a quote." "Book me a haircut for Friday afternoon." "Reorder my usual from this shop." The agent goes and does it.
Most websites are still built only for a human with a mouse. An agent visiting one has to guess: which link is the real search box, which button actually submits the form, which field is the email address. Sometimes it gets it right. Sometimes it fills the wrong field, or gives up.
In short
WebMCP is a new Chrome capability (currently an origin trial) that lets a website register tools — search, form submission — an AI agent can call directly, skipping the guesswork of parsing raw HTML. We built it live on cmo.works this month: 1 search tool for the blog, and 2 forms an agent can fill out and submit directly. This article covers what it actually looks like for a real business, how we tested it, and 2 real bugs it exposed that most sites adding this will hit too.
What This Actually Looks Like
A prospective client asks their AI assistant to look into a few fractional CMOs and request quotes. On a WebMCP-ready site, the assistant finds the right page through the site's own search tool, then fills out and submits the contact form with the right details — a real inquiry, correctly filled in.
A shopper asks their assistant to reorder their usual coffee. On a WebMCP-ready storefront, the assistant searches the catalog through the site's own tool and completes checkout through a form built to be submitted this way.
Someone asks their assistant to book a haircut for Friday afternoon. A WebMCP-ready booking form lets the assistant see the real available slots and submit the booking directly.
The mechanism is always the same 2 shapes: a tool that searches, and a tool that submits a form. What changes from business to business is only what sits behind them.
What Is WebMCP, and How Is It Different From a Sitemap or robots.txt?
robots.txt and sitemap.xml are about discovery — what exists on a site, and what's allowed to be crawled. Neither has any concept of search or form submission; both are just URLs and a set of allow/disallow rules. WebMCP sits at a different layer: it's not about helping an agent find the site, it's about what the agent can actually do once it's already there.
| Question It Answers | Who Acts on It | |
|---|---|---|
| robots.txt / sitemap.xml | What can be crawled, and where is everything? | Search & AI crawlers — discovery only |
| Schema.org / structured data | What does this content actually mean? | AI Overviews, LLM answer engines |
| llms.txt | How should an LLM use and cite this site? | LLMs researching or citing content |
| WebMCP | What can an agent actually do here, right now? | AI agents acting live, on a real visitor's behalf |
Getting found and understood by an AI model in the first place is its own discipline — matching what someone's actually asking, structuring content so a model can lift a direct answer, earning the signals that get a brand mentioned by name. We've written before about what actually separates a search ranking, a direct answer and an AI citation, and none of that work goes away here. WebMCP picks up right after it succeeds: once an agent has found your page and decided it's relevant, this is what lets it act — fill in a form, complete a task.
How We Actually Built It
We shipped 2 kinds of tools on cmo.works this month: 1 imperative, 1 declarative (on 2 forms).
The imperative one, search_cmo_works_articles, lets an agent search the blog by keyword:
document.modelContext.registerTool({
name: 'search_cmo_works_articles',
description: 'Search CMO Works blog articles about fractional CMO leadership, marketing budgets, AI visibility and GEO...',
inputSchema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] },
annotations: { readOnlyHint: true, untrustedContentHint: false },
execute: async function(inputs) { /* keyword-overlap search over our own article list */ }
});The article list it searches gets rebuilt from the live blog on every deploy, so a new post becomes searchable automatically, this one included.
Ask it something like "how do you track when ChatGPT or Claude mentions a brand" and it correctly surfaces our own breakdown of measuring brand mentions and citations across ChatGPT, Claude and Google's AI Overviews — a real query, a real result, exactly what the tool is for.
The declarative tools sit directly on 2 real forms:
<form method="POST" name="contact"
toolname="submit_marketing_inquiry"
tooldescription="Submit a business inquiry to..."
toolautosubmit>
<input name="name" toolparamdescription="Full name of the person submitting the inquiry." required />
...
</form>
toolautosubmit is the real decision point: without it, an agent can only pre-fill the form for a human to review and click send; with it, the agent can submit on the person's behalf. We turned it on deliberately, on both forms, specifically to see real volume and lead quality before deciding anything further.
Beyond our own site, the same 2 shapes fit almost any business:
- E-commerce: an imperative "search products" tool plus a declarative checkout form — an agent handling a routine purchase can complete the whole flow.
- Booking-based services (clinics, salons, consultants, agencies): a declarative "request an appointment" tool — an agent picks a slot and submits it directly.
- SaaS: the exact contact-form pattern above, applied to "start a free trial" or "request a demo."
- Any content-heavy site (publishers, knowledge bases, docs): the exact search pattern above — an agent gets real, grounded answers about what's actually on the site.
How to Test It
The hard part isn't writing the tool — it's testing something that, as of today, almost no browser exposes by default. document.modelContext only exists in Chrome with the origin trial active and the token matching the real, live domain.
1. Stub the Registration, Run the Real Code
Replace document.modelContext with a fake object whose registerTool() just captures what gets passed to it, then let the page's real script run. You get the actual tool object, with its real execute() function and real schema, without needing a browser that supports the API at all.
2. Test Against Adversarial Inputs
Single stopwords, empty strings, gibberish. This is exactly what caught our own real bug: our search scored by plain keyword overlap with no stopword filtering, so a query like "the" matched an arbitrary article, when the correct answer was no results at all.
3. Test Form Submission the Way an Agent Actually Would
Stub the network call, fill fields programmatically, call form.requestSubmit(), and check exactly what got sent.
4. Use Chrome's Own Audit Tooling as a Second Opinion
PageSpeed Insights has an experimental "Agentic browsing" category that lists every registered tool exactly as Chrome sees it — name, description, full JSON schema — and flags schema problems directly.
5. Verify Behavior Directly, Every Time
More than once, what Chrome's own docs described and what we actually observed in testing didn't match. Treat anything this new as something to check yourself.
The Analytics Nuance Almost Everyone Will Hit
An analytics event that only fires from a submit button's click handler, separate from the form's actual submit event, silently stops firing for agent-driven submissions.
Our own contact form had exactly this shape. Invisible in every normal test, because a human clicking the button fires the click handler and the real submission together. The moment an agent uses toolautosubmit, it submits the form programmatically: Chrome's implementation dispatches a real submit event straight to the form. The button's click handler, which only runs on an actual click, never fires. The lead goes through completely normally. The conversion event just never happens.
We only found this by deliberately testing a programmatic submission and comparing the network request against the analytics event.
The general check for anyone doing this: for every conversion event tied to a form, find out exactly what it's bound to — the form's own submit event, or a proxy like a button click that happens to co-occur with a human filling the form. A proxy-bound event opens a measurement gap the moment toolautosubmit ships. The fix is always the same: move the event into the form's own submit handler.
Other Practical Nuances
- "WebMCP form coverage: Not applicable" in PageSpeed is a good sign. It's a coverage check that lists forms lacking annotations — an empty result means it found none, full coverage already.
- Hidden fallback forms need to actually stay excluded. Static-hosting form systems sometimes keep a real, duplicate <form> around purely for build-time detection. Worth confirming your own audit setup excludes it the same way a live, JS-enabled agent would.
- Declarative tools only attach to <form> elements. A plain CTA link has no declarative WebMCP equivalent — a website has no way to actually complete an extension install or app download on a user's behalf regardless, since the browser blocks that by design.
- Origin trial tokens expire, silently. Ours runs out mid-November 2026. Nothing errors when it does — the tool just goes back to being invisible to real visitors, exactly as before it shipped.
- toolautosubmit is a business decision. It determines whether an agent can only prepare a request for a human to send, or send it directly — decide deliberately, and watch real lead quality and volume for a while afterward.
Where to Start
You don't need every form on your site wired up on day 1. Start with whichever single form actually generates a lead or a conversion today, add the declarative attributes to it, and watch what happens for a few weeks before deciding whether to expand further or add an imperative search tool on top.
The origin trial itself is free to register and takes a few minutes at Chrome's own origin trials console. The harder part is everything covered above: testing it properly, and checking your analytics still see what actually happens.
Frequently Asked Questions
What is "agentic browsing"?
AI agents acting directly on web pages on a real person's behalf: searching, filling in forms, and completing tasks.
Does WebMCP work in every browser?
Not yet — it's a Chrome origin trial (Chrome 149 to 156 as of writing), and each site needs its own registered token for the feature to activate for real visitors.
Can an agent submit my forms without anyone reviewing them first?
Only if the form explicitly opts in with toolautosubmit. Without it, an agent can pre-fill a form, but a human still has to click submit.
Do I need to rebuild my website to add this?
No — the declarative version is HTML attributes added to forms that already exist; the imperative version is a small script alongside your existing content.
About the Author
Ruslan Abdrakhmanov is an Executive Marketing Advisor and CMO with 13+ years leading international marketing teams across EMEA, SEA, and Americas. Expert in data-driven growth strategies with the track record growing B2B and B2C businesses.
Address your challenges and strengthen your team with tailored support:
Let's Make It Done
Share your context and I'll help you find the best solution for your business growth.
