Google WebMCP: how to make your website agent-ready

Someone opens your website with an AI agent beside them and says: "Find the right service, work out whether it fits, and start a conversation."

Today, the agent has to do what a human does. It reads the page, guesses which button matters, fills the form, and hopes the UI has not moved since it looked. That is impressive when it works. It is also a fragile way to run a business interaction.

WebMCP is Chrome's attempt to give the website a better way to answer. Instead of leaving an agent to infer your interface from pixels and HTML, your site can declare the things it knows how to do: search the site, check availability, calculate a price, start a support request, add an item to a basket. The browser presents those actions as structured tools, and the agent supplies structured inputs.

You will often hear this called "Google WebMCP" because it is being developed and trialled through Chrome. The important distinction is that it is a proposed web-platform API, not a Google search product and not a new way to rank higher in results. The Chrome documentation describes it as a way for websites and agents to work together through browser-mediated tools.

That difference matters. This is not a reason to sprinkle some tags on every button and wait for AI traffic. It is a way to make a valuable task more dependable after a user has decided that an agent should help them do it.

What WebMCP actually changes

Think about booking a consultation. A human sees a calendar, a name field, an email field and a submit button. An agent sees a collection of visual clues and has to reverse-engineer the same flow. It can get there, but it may choose the wrong appointment type, lose its place when the page updates, or be unable to explain what happened afterwards.

With WebMCP, your site can publish a small contract instead:

• The action is called book_consultation.
• It is for reserving a 30-minute introduction call.
• It needs a date, time, name and email address.
• It returns either a confirmation or a useful reason it could not complete the booking.

The browser gives that contract to a WebMCP-aware agent. The agent does not need to discover a hidden DOM path or simulate a shaky sequence of clicks; it calls a well-described capability and your existing site logic handles it. The user remains in the loop where confirmation is appropriate.

That is why the right mental model is an API for a website's useful actions, not an AI chatbot embedded in the site.

WebMCP is not MCP — and they are better together

The names are confusingly close.

Model Context Protocol (MCP) is a protocol for connecting AI clients to external tools and data: a company database, a CRM, a design system, a code repository. It answers: "what can this assistant reach?"

WebMCP works at the browser and page level. It answers: "what can this website do for an agent, right here, in this user session?"

They solve neighbouring problems. An MCP-connected assistant might retrieve a customer's account context. When it opens the company's website, WebMCP can make the site's safe, user-facing actions explicit. Neither replaces the other, and neither one gives an agent permission to ignore login, payment, consent, or your server-side rules.

For a more technical comparison, Chrome's WebMCP and MCP overview is the source of truth. For a business, the useful conclusion is simpler: keep your data access controlled wherever it belongs, and expose only the narrow website actions you are prepared to support.

Why a business might care

The immediate value is not "AI will visit our website." The immediate value is that an agent helping a real customer can complete an existing journey with fewer guesses.

Here are the places that tends to matter:

• Support: an agent can search a knowledge base, collect the minimum details for a support request, and show the customer exactly what it submitted.
• Sales: it can find the right service or product, qualify a basic request, and prepare a call or demo booking for the user's confirmation.
• Self-service: it can run a quote, eligibility, compatibility, or savings calculator without trying to imitate a person clicking through every control.
• Complex forms: it can map a user's intent to the right fields while leaving the final review and submit step visible to the person.
• Internal portals: for authenticated employees, it can navigate a known workflow more reliably than screen-scraping an interface that changes every sprint.

This is especially valuable when a journey has a clear finish line but a busy or dynamic interface. A normal browser agent can still use the page; WebMCP reduces the number of ambiguous steps between "I want this" and "it is done."

There is a quieter benefit too. When you write down a tool's purpose, inputs, outputs, error cases and approval point, you learn where your own customer journey is vague. The tool description becomes a small product specification. If you cannot explain an action without saying "the agent can probably work it out," the human journey may not be as clear as you thought either.

The honest limits before you start

WebMCP is promising, but it is early. Chrome currently offers it through an origin trial, and the specification and APIs are actively evolving. Support is not universal across browsers or agents. An integration must therefore be progressive enhancement: people can use the site normally, and unsupported browsers simply do not see the extra tools.

It also does not guarantee discovery, traffic, leads, or conversion. An agent still chooses whether to use a tool. A user still chooses whether to buy. The best WebMCP integration in the world cannot rescue a confusing offer, a slow checkout, or a form nobody wants to complete.

Finally, structured tools do not make agent behaviour deterministic. They reduce ambiguity; they do not remove it. Chrome explicitly recommends evaluating whether agents understand when to call each tool, how to call it, and what a good result looks like before release. Read its guide to WebMCP evaluations before you put a consequential action in front of customers.

How to bring your website to WebMCP, step by step

Do not begin with every button on your site. Begin with one high-frequency, low-risk job that already works for humans.

1. Pick a customer journey, not a feature

Start with the job the visitor is trying to finish: "find the right guide," "check whether you serve my area," "calculate the monthly saving," or "send a support request." Chrome calls these critical user journeys in its WebMCP use-case guidance.

Score each candidate on three things:

• Value: does it save a customer or employee a real amount of time or uncertainty?
• Risk: can a wrong result cause money to move, data to leak, or an irreversible change?
• Readiness: do you already have a reliable function or endpoint that completes the task?

The best first tool is usually informational or reversible. A product finder is better than placing an order. A calculator is better than issuing a refund. A support-request draft is better than changing a customer's plan.

2. Turn the journey into one narrow action

Name the tool after an outcome, not an interface element. find_compatible_plan is useful. click_next_button is not.

Give it a description that says when an agent should use it, not just what it returns. Define only the parameters the action genuinely needs, with types, allowed values and examples where they reduce ambiguity. Then decide what a success and a failure look like.

A good failure is specific: "No appointments are available on that date; ask for another weekday." A bad failure is a thrown exception or a vague "something went wrong." An agent can recover from the first one. It cannot do much with the second.

3. Reuse your business logic — do not create an agent-only back door

The tool should call the same validated service, permission checks and rate limits as your normal UI. WebMCP makes an action easier for an agent to find; it must not make the action easier to abuse.

Keep authentication and authorisation on the server. Validate every input again. Never put an API key or privileged operation into browser code merely because the browser is the entry point. For anything that changes data, use idempotency protections where duplicate requests would be harmful.

This principle also makes maintenance cheaper. When the underlying booking, search or quote flow changes, both the human UI and the agent tool continue to use one source of truth.

4. Choose the right integration shape

WebMCP has two practical routes.

Use the imperative API when the action needs custom JavaScript: client-side state, navigation, several steps, or a result generated by an existing function. In simplified form, that looks like this:

document.modelContext.registerTool({
  name: "calculate_quote",
  description:
    "Calculate an indicative project range when a visitor asks for a quick estimate.",
  inputSchema: {
    type: "object",
    properties: {
      teamSize: { type: "number", description: "Number of people who will use it." },
      workflow: { type: "string", description: "The business process to improve." },
    },
    required: ["teamSize", "workflow"],
  },
  async execute({ teamSize, workflow }) {
    const quote = await calculateQuote({ teamSize, workflow });
    showQuoteInThePage(quote); // The person watching sees the result too.
    return { content: [{ type: "text", text: quote.summary }] };
  },
});

Use the declarative API for an ordinary HTML form. Add a toolname and tooldescription to the form, then describe each meaningful control. The browser can turn the form into a tool while keeping the form visible to the person:

<form toolname="request_support"
      tooldescription="Prepare a customer-support request when the visitor needs help."
      action="/support">
  <input name="email" type="email" required
         toolparamdescription="The address where the customer wants a reply." />
  <textarea name="problem" required
            toolparamdescription="What the customer needs help with."></textarea>
  <button type="submit">Send request</button>
</form>

Do not add automatic submission by default. For actions that contact a person, spend money, change records, or create a commitment, let the user inspect and submit the prepared form. Chrome's declarative API guide explains the optional auto-submit behaviour and the browser feedback it provides.

5. Make the action visible and consentful

An agent should not silently do something that a person would reasonably expect to see. When a tool runs, update the same page state a human interaction would update: show the search results, selected slot, calculated total, draft ticket, or confirmation.

For read-only actions, say so in the tool metadata. For anything that mutates state, make the consequence clear and ask for confirmation at the right moment. The sensible default is: the more expensive, irreversible, personal, or regulated the action, the closer a human should be to the final click.

6. Configure the browser support deliberately

Because the feature is experimental, check the current Chrome origin-trial requirements before launch. You will typically need the trial token on the correct origin and a permissions policy that allows the tools feature. Treat the token like a deployment dependency: record its expiry date, test it on the production domain, and set a reminder well before it lapses.

Also isolate WebMCP-specific code behind a capability check. Your website should render and work identically for a visitor using Firefox, Safari, an older Chrome version, or a browser with no agent attached.

7. Test the tool like a product, not a code snippet

Run ordinary application tests first: valid inputs work, invalid inputs produce actionable errors, access controls hold, duplicate requests do not cause damage, and the human UI still works.

Then create a small evaluation set for agent use. Include prompts that should call the tool, similar prompts that should not, incomplete requests, malicious-looking input, unavailable options and double-submit attempts. Check not only whether the code ran, but whether the agent chose the right tool and gave the user an honest outcome.

Instrument the result. Track tool selection, validation failures, latency, completions, user cancellations and the business metric you expected to improve. If booking completion does not rise or support handoff quality does not improve, the answer may be to retire the tool—not to add another layer of AI.

The security work is not optional

Giving agents structured actions concentrates risk in a useful place: you can now see exactly what the action is meant to do. But it is still an agent acting in an authenticated browser session, which makes sloppy implementation dangerous.

Chrome's agent security guidance highlights malicious tool descriptions, contaminated tool output and indirect prompt injection as real concerns. The practical response is familiar security hygiene, applied more rigorously:

• Keep tool descriptions short, factual and free of hidden instructions.
• Return the minimum data required for the next decision; mark third-party content as untrusted where supported.
• Authorise every state-changing action server-side, even when the user is already signed in.
• Scope tools to the current origin and current user, rather than letting them become a bridge to unrelated systems.
• Require confirmation for meaningful changes and log enough context to investigate disputes.
• Rate-limit and monitor tools just as you would an API endpoint.

There is no magic prompt that turns this into a solved problem. Agent security needs layers: bounded tools, conventional access control, user confirmation, small outputs, monitoring, and an easy way to turn a tool off if it behaves badly.

What this looks like on our own website

QwertyBit already uses WebMCP as progressive enhancement. A supporting browser can discover structured actions to search the site, find services and case studies, use the free tools, and prepare a contact request. A normal visitor sees the same website and the same forms.

The important choice was not to make every interaction agentic. We exposed things where a well-described action is more useful than a sequence of guessed clicks: searching a growing body of content, choosing a calculator, and moving from "I have a problem" to the right conversation.

If you are building this into a Next.js or React site, the implementation pattern is straightforward: keep the reusable business function separate; register a thin browser tool that calls it; update the visible component state from the tool execution; and unregister the tool when that page disappears. The browser API is moving, so keep that compatibility layer small and isolated rather than scattering browser-specific calls through the app.

A sensible first 30 days

You do not need an "agent strategy" deck before you try this. You do need a small, accountable experiment.

1. Week one: map three customer journeys, pick the lowest-risk high-value one, and define the baseline metric.
2. Week two: build one narrow tool on top of the existing validated workflow; keep a human confirmation step for any write.
3. Week three: test it with a set of realistic and adversarial prompts; fix unclear descriptions, validation gaps and poor failure messages.
4. Week four: release to a limited audience, observe completions and cancellations, and decide whether the measured outcome justifies maintaining it.

Success is not a press release that says your site is AI-ready. Success is a customer reaching the right outcome more often, with less confusion and no new security problem.

The trade-off worth making

The web is changing from a place agents merely look at into a place where they can ask for clearly bounded help. WebMCP is one early piece of that change. It will mature, its API may change, and some businesses will discover that their first use case was not worth the maintenance.

That is fine. The durable work is not the trial token or the tool-registration call. It is learning to describe your best customer journeys clearly, separating useful actions from risky ones, and keeping the customer in control when a machine helps them navigate your business.

If that sounds like the kind of decision you want help making, talk to QwertyBit. We can map the customer or operational journeys where an agent is genuinely useful, then build the workflow, safeguards and measurement around it. And if the opportunity is broader than a website interaction, our AI agent development service is built for the business process behind the page—not just the shiny demo on top of it.