What is WebMCP?
WebMCP is a proposed web standard that lets a website expose structured actions to AI agents. Instead of relying entirely on an agent interpreting buttons and fields, a developer can describe a task and the information needed to carry it out.
Think of a booking page: an agent might help a visitor find available appointments while the website remains the place where availability, choices and confirmation appear. The user still needs a usable interface.
Status checked: 28 October 2026. Chrome’s official overview, updated 7 October, describes WebMCP as a proposal under active development. It documents an origin trial starting with Chrome 149 and a local testing flag. This is not a promise that every browser or AI assistant supports your implementation.
How could it work on a business website?
Chrome documents two approaches: JavaScript-defined tools and annotations on HTML forms. They let developers describe interactions explicitly. The API is primarily intended for browser workflows with a human involved; agents must visit the site to discover its tools. Check current documentation before choosing an implementation.
Here are three illustrative product ideas, not claims about features already installed on WebHolick:
- A service agency: let an agent find services matching a visitor’s project, then prepare an enquiry for review. Preparing a draft should not silently send it.
- An online store: filter products by a stated budget and size. Show whether prices include delivery before the visitor decides to buy.
- A booking business: show available appointments for a chosen day. Keep checking availability separate from reserving a slot.
The useful starting question is: which task causes visitors to repeat information or navigate unnecessary screens? A small, well-defined action is easier to evaluate than a promise to automate the entire website.
A practical example: finding a suitable service
Suppose a visitor says, “I need a small online shop with card payments.” A carefully scoped service-finder could accept a project type, required features and preferred launch window. It would return relevant service pages and any questions that remain unanswered.
Design its output so the visitor can tell a recommendation from a commitment. A service match is not a quote, an accepted deadline or a confirmed contract. If the visitor has not supplied a budget, the system should leave it unknown instead of inventing one.
For this example, a useful success criterion is simple: does the visitor reach the right service information with fewer corrections, while retaining control over any enquiry? Compare against the ordinary navigation flow using the same scenarios.
Plan the tools before writing code
Chrome’s best-practices guidance recommends focused tools, clear names, semantic HTML and registration that reflects the page’s current state. Names should distinguish opening a process from completing it.
For your own project, write a short contract for each proposed action:
- Purpose: what visitor problem does it solve?
- Inputs: which values are required, optional or invalid?
- Effect: does it only read information, prepare a draft or change something?
- Result: what appears on screen after success, failure or cancellation?
- Availability: when should the action be usable?
For example, “prepare enquiry” and “send enquiry” need different descriptions and outcomes. Avoid vague labels such as “handle customer” that conceal multiple operations.
Keep permissions and confirmation explicit
Chrome’s tool security guidance highlights prompt-injection risks, careful sharing across origins and annotations that identify read-only, consequential or untrusted-content situations. Those annotations communicate intent; they should not replace your application’s access checks.
As a practical implementation rule, validate inputs and enforce account permissions in the application’s trusted backend. An agent should not gain access to another customer’s order merely by supplying its reference number. Ask for clear confirmation before an action creates a real obligation, such as a paid booking.
Also inspect the information returned by read-only actions. Reading data can still expose private details. A product search generally needs product facts, not a customer’s full account history. Record enough information to investigate failures without copying sensitive message content into analytics.
A small pilot checklist
Use a staging environment and test accounts first. This proposed checklist is a starting point for your team’s QA, not a report of measured WebMCP results:
- Choose one low-risk task and document its normal human-operated flow.
- Check the current browser, trial and API requirements in the official documentation.
- Keep the ordinary interface working when the experimental feature is unavailable.
- Test missing fields, invalid values, expired sessions and empty results.
- Test cancellation and repeated requests, especially before enabling actions that change records.
- Verify that on-screen messages match what actually happened.
- Compare task completion, corrections and user understanding against the original flow.
- Define an owner and a way to disable the pilot if behaviour becomes unreliable.
Should your business adopt WebMCP now?
A pilot may make sense when you already have a working site, a specific task to improve and a developer who can maintain an experimental integration. If your contact form is broken or your product information is incomplete, fix those fundamentals first.
Do not treat this article as evidence that WebMCP will improve search rankings or guarantee discovery by AI assistants. Evaluate it for the interaction it enables and the results of your own tests.
Start with WebHolick’s contact form guide for clearer forms, or the website project brief checklist to define scope. Our website development and UI/UX design services can help plan and build practical website experiences. Tell us which customer task you want to improve.