Picture a customer asking an assistant to find a local business, understand its services and help prepare an enquiry. The familiar website is still there. What changes is how the customer moves through it.
That is the business question behind WebMCP, a proposed web standard described in Google’s Chrome documentation. It gives a website a way to describe particular actions to a browser agent, rather than leaving the agent to infer everything from buttons and page layout. Google’s documentation, updated on 7 October 2026, lists an origin trial from Chrome 149. This remains developing technology, not a capability every customer’s browser can use.1
A useful doorway, rather than another chatbot
Many discussions about AI on websites start with a chat bubble. This development asks a different question: could the actions your website already offers be described clearly enough for an assistant to help someone use them?
Think of the difference between walking into an unfamiliar building and finding a well-labelled reception desk. The desk does not change the services inside. It makes the next step less ambiguous. Our interpretation is that a similar principle could matter for digital customer journeys: make a limited set of useful actions clear, predictable and easy to check.
For a small business, that might mean finding a service, choosing a relevant enquiry form or preparing a request. It does not have to mean building an autonomous salesperson. A feature that reliably helps a customer complete one ordinary task could be more useful than an impressive-looking demonstration with no practical purpose.
What could that look like in real life?
The benefit to test would be enquiry quality, not whether the site can display an AI badge. Does the business receive more useful information? Does the customer understand what was sent? Is the ordinary form still straightforward when an assistant is unavailable?
Those are questions a business owner can judge. They also keep the design grounded: the website still needs clear services, sensible questions and a working contact route. Adding another way to interact with a confusing process would preserve the confusion.
Discovery is not the same as being understood
There is an important limit here. A website describing an action to an agent is different from that website being recommended in a search result. In Google’s documentation, a client must visit a site to discover its callable tools. This is not a promise of search visibility or a way to buy a place in an AI answer.1
For that reason, we would treat agent-friendly features as a possible improvement to an existing customer journey. Clear wording, accessible forms and accurate business information remain sensible work in their own right. They should not be postponed while waiting for an emerging standard.
Keep the customer in control
A request for information and a commitment to spend money are different actions. Any experiment should make that boundary obvious. Our recommendation is to begin with low-consequence assistance, show the proposed result and retain the same server-side checks that apply to a person using the site directly.
Customers should be able to correct information and use the ordinary interface. A tool description should never be treated as permission to see another person’s records or bypass a business rule. Google’s documentation also identifies sensitive actions and points implementers to user-confirmation and security guidance.1
What should a small business do now?
- Choose one difficult step. Look for repeated customer questions or incomplete enquiries.
- Improve the human journey first. Make the information, questions and confirmation clear.
- Ask for a bounded demonstration. Agree the supported browser, success measure and fallback before committing to a build.
For a simple brochure site with very few enquiries, an experiment may not be worthwhile yet. For a business with a repeated, structured customer task, it could be something to watch. The opportunity is a clearer interaction—not a reason to rebuild a useful website merely to follow a label.
Sources and editorial notes
Checked 27 October 2026. Google documentation updated 7 October 2026. This is an original SSC Digital explainer, with AI-assisted research and drafting, checked against the sources below. Examples and recommendations are our interpretation, not claims of measured results.
- Google Chrome for Developers: WebMCP
Published 18 May 2026; updated 7 October 2026. Proposed standard, trial status, discovery and interaction limits.
- Google Chrome for Developers: WebMCP early preview
Published 10 February 2026. Background to the declarative and imperative proposals.
Corrections: none recorded at publication. Send a correction or question.

