For two years the entire conversation about AI and marketing has been about being found. Will the model cite me? Do I show up in the answer? That is a real question and I have written about it before. But it is only half the journey, and we are about to find out that it was the easier half.
Agents have started doing things on websites, not just reading them. They book the table, run the checkout, submit the form. And they are doing it on sites that were built for people, which means the agent has to squint at a screenshot, guess which div is the date picker, and hope. Chrome's own documentation has a name for this: actuation — an agent simulating mouse clicks and typing as though it were a human user [1].
It works about as well as you would expect. And it fails at the worst possible moment: the last step, after you have already won the discovery battle.
WebMCP is the fix. I think it is the most consequential change to how the web works since responsive design, and I think most marketing teams are going to treat it as a developer ticket and miss the point entirely.
WebMCP is a proposed web standard that lets your site hand agents a defined set of tools instead of making them guess. Rather than an agent inferring that the button labeled "Go" runs a search, your page declares it: here is a tool called search_products, here is what it does, here is the data it needs.
There are two ways to do it [1]:
Two things matter strategically here. First, it is a progressive enhancement — if an agent finds no tools, it falls back to guessing, exactly as it does today. Nothing breaks. Second, the tools run visibly on your page. The form fills in where the user can see it. Your brand and your design stay on screen, and by default a human still clicks submit [1][3].
That last detail is not a technicality. It is the difference between agents disintermediating your brand and agents making your brand easier to use.
These get framed as competitors. They are not. The Chrome team's own analogy is a call center versus an in-store expert: MCP is available anywhere at any time and pulls from your backend; WebMCP exists only on your page and helps an agent understand an interface built for humans [2].
| MCP | WebMCP | |
|---|---|---|
| Where it lives | Your backend, as a server you build and run | Your front end, on the page itself |
| What it is good at | Pulling data and running core system tasks | Completing actions inside a human interface |
| Availability | Any platform, any time | Only while your page is open |
| Cost to start | Real engineering — a server to build and maintain | Attributes on a form you already have |
| Who should own the decision | Engineering and data | Marketing, with engineering |
Most organizations will end up running both. If you have already been building specialized agents with shared context and skills, MCP is how those agents reach your systems. WebMCP is how anyone else's agent reaches your customer experience.
Here is the part I have not seen anyone say, and it is the reason I think this belongs on a marketing leader's desk and not only a developer's.
When an agent arrives at your site and asks what it can do, your tool list is the answer. It is a short, machine-readable, unambiguous statement of what your business is for. Not your positioning statement. Not your homepage headline. The three to five verbs you chose to expose.
Think about what that means. For twenty years we have written positioning that was aspirational and then let the actual experience drift. An agent does not read your aspiration. It reads your tools. If your tool list says request_a_demo and nothing else, you have told every agent on the internet that your website is a lead capture form. If it says check_availability, compare_plans, and start_setup, you have told it you are a place where decisions get made.
That choice — which actions are worth exposing, in what order, described in what language — is positioning work. The descriptions themselves are copy, and they are copy with an unusually direct performance signal: when the agent picks the wrong tool or fills the wrong field, it is almost always your description that is wrong, not the model [3]. You will be able to test and rewrite them the way you would test a headline.
This is the same argument I made about outcomes being the strategy. The tool list forces you to answer what your site is actually for, in a format that does not allow hand-waving.
Discovery and actuation are two different problems and you can lose either one independently.
AI visibility gets the agent to you. WebMCP determines whether it can finish once it arrives. The failure mode nobody is planning for is winning the first and losing the second — being the brand the model recommends, and then being the site where the agent gets stuck on a date picker and quietly moves to the competitor whose booking form it could actually operate.
Worth being precise about the sequencing, though: today, an agent has to visit your site to discover you have tools at all [1]. WebMCP is not a discovery channel and will not send you traffic. It is what protects the traffic you have already earned.
The honest answer is that this is a small project, and that is exactly why you should do it now.
1. Pick your actions before you write any code. List the three to five things people actually come to your site to do. Book, buy, search, compare, subscribe, get support. This is the positioning conversation from above and it should involve whoever owns the customer, not just whoever owns the codebase. Start with one low-risk action — a search box or a newsletter signup — not checkout [3].
2. Start with a form you already have. The declarative API is attributes on existing HTML. Your form's validation still applies to agents exactly as it applies to people, so an agent submitting garbage gets rejected the same way a person would. You are not building a parallel set of guardrails [3].
3. Test it like a campaign. Turn on the Chrome flag at chrome://flags/#enable-webmcp-testing, install the Model Context Tool Inspector extension, and prompt it. Watch which tool the agent picks and what it puts in each field. When it gets it wrong, rewrite the description and run it again [1][3].
4. Decide what an agent is allowed to do without a human. This is the governance step and it is not optional. Mark read-only tools as read-only. Flag any tool that returns user-generated content — reviews, comments, anything you did not write — so the agent treats that text as data rather than instructions, because otherwise it is an injection path straight into your customer's session. And leave auto-submit off for anything that spends money or changes an account [3].
Then ship it. Chrome runs a time-limited origin trial from version 149 that lets you serve tools on your live site rather than only on your own machine [1].
I would rather you go in clear-eyed than excited, so here is the other side, mostly from the people building it [1]:
Which is to say: this is an option, not a growth plan. Do not put it in a revenue forecast. Put it in the budget as cheap insurance with asymmetric upside.
Everyone reaches for the mobile analogy here, and it fits — years of feeling optional, then suddenly mandatory. But the useful part of that story is not the timing. It is what mobile actually forced.
Responsive design was never really about screen width. It forced a generation of companies to decide what mattered most on a page, because there was no longer room for everything. The constraint produced the clarity.
WebMCP is that constraint again, and harsher. You do not get a hundred links and a hero video. You get a handful of verbs. An agent will ask your business what it can do, and you will get a few words to answer.
Most companies will let that answer be decided by whoever happened to pick up the ticket. The ones who treat it as what it is — a positioning decision with a test loop attached — are going to end up with websites that work when someone's agent shows up, and a much sharper account of what they are for.
The work starts with a question you can answer today, without writing a line of code: if an agent could only do five things on our site, which five, and why those?
Mike Bloomstine helps leaders navigate the shift from activity-led marketing to outcome-based systems. To talk through what this looks like for your business, visit mikebloomstine.com.
I help B2B and B2C teams build marketing engines that compound — strategy first, systems underneath.
