For most of the web's history, the goal of a website has been to be seen. We optimised for search engines so people could find us, and more recently for answer engines so an AI would cite us when it replied. That work, what we have called answer engine optimisation, still matters. But it addresses only the first half of a much larger change. Being found is not the same as being useful. The more consequential shift, now taking shape inside the browser itself, is the move from a website an AI can read to a website an AI can operate. Put plainly, your website is becoming an API for AI agents, and the standard that makes that possible already has a name: WebMCP.

Almost no one is talking about it yet. That is precisely why it is worth your attention now, in the same way the businesses that understood answer engines early are the ones being recommended by AI today.

From answer engines to the agentic web

The last two years of digital strategy have been about visibility inside AI. Generative engine optimisation and answer engine optimisation taught us to structure content so that large language models would surface and cite it. That is discoverability, and it remains the foundation.

What has changed is that AI is no longer only answering questions. It is beginning to take actions. The agentic web describes a web navigated not only by people but by autonomous AI agents acting on their behalf: comparing options, completing forms, retrieving documents, requesting quotes. Agentic browsers can already carry out multi-step tasks across sites, and in May 2026 Google added an Agentic Browsing audit to its Lighthouse tool, scoring how well a site is built for an AI agent to read, understand and act on. When a platform as central as Google begins measuring your site's readiness for agents, the direction of travel is no longer in doubt.

The problem is that, today, an agent acts on your website by pretending to be a human. It loads the page, looks at the rendered layout, infers where the controls are, and clicks. That approach is slow, fragile and error-prone. A small redesign can break it, and a misread label can send it down the wrong path. For a business where a transaction or a specification carries real weight, an agent guessing its way through your interface is not a channel you would choose.

What WebMCP actually is

WebMCP, the Web Model Context Protocol, removes the guesswork. It is a proposed web standard developed through a W3C Community Group, put forward jointly by engineers at Google and Microsoft, and it lets any website declare its own capabilities as structured, callable tools that an AI agent can invoke directly.

It descends from the Model Context Protocol, the open standard that defined how AI systems connect to external tools and data. MCP solved that on the server side. WebMCP brings the same idea into the browser through a new JavaScript interface, navigator.modelContext. A site registers tools, each with a name, a description and a structured schema for its inputs and outputs. The agent reads those definitions and calls the tool with clean, typed data, rather than scraping a page meant for human eyes. Your website, in effect, becomes its own API. And because the tools execute in the browser using logic the site already has, much of this needs no new backend at all.

The timeline is short and fast. An early implementation known as MCP-B appeared in January 2025. Google and Microsoft published a unified proposal in August 2025. The W3C Community Group formally accepted it in September 2025, and Chrome shipped an early preview in version 146 in February 2026. The reliability case is the headline: by exchanging structured data instead of interpreting a screen, agents using tool calls reach task accuracy of around 98 per cent, far above the rates seen when they navigate by sight.

What it looks like in practice

Conceptually, exposing a tool is as simple as describing an action your customers already take. The exact interface is still settling, but the shape is clear:

navigator.modelContext.registerTool({
  name: 'get_quote',
  description: 'Return an indicative quote for a shipment',
  inputSchema: { origin: 'string', destination: 'string', weightKg: 'number' },
  execute: async (input) => { /* run the existing quote logic */ return quote; }
});

A freight network might expose get_quote and track_consignment. A manufacturer might expose find_by_specification and get_current_certificate. A professional services firm might expose check_availability and book_consultation. Each one is a real customer action, now offered to an agent as a reliable, governed function instead of a page to be deciphered.

Why this matters most for complex industries

In sectors where accuracy is not negotiable, the stakes are different. A procurement lead in aerospace, energy or defence increasingly delegates the first pass of research to an agent: confirm a material grade, check that a certification is current, compare two specifications, establish a lead time. If your site can only be read, the agent infers, and an inference about a safety certificate or a compliance standard is exactly the class of error these industries cannot absorb. If your site exposes the fact directly, as a tool returning verified data, the agent reports something true. You move from hoping the AI reads you correctly to controlling precisely what it can retrieve and how.

There is a governance dividend in that control. A declared tool is an explicit boundary. You decide which actions an agent may call and which it may not, you validate the inputs, and you can log every request. That is a far stronger and more auditable position than leaving an autonomous system to interpret an entire page and act on whatever it concludes. For regulated businesses, being able to show exactly what an agent was permitted to do, and what it did, is not a nice-to-have. It is the difference between adopting this safely and avoiding it.

AEO, GEO and WebMCP: the new web stack

It helps to see these as layers rather than competitors. Search and answer engine optimisation make you discoverable, so the AI knows you exist and cites you. Structured data, Schema.org markup and emerging conventions such as llms.txt and Microsoft's NLWeb make you readable, so the AI can parse what you offer without ambiguity. WebMCP makes you actionable, so the AI can do business with you. None of these replaces the one beneath it. WebMCP does not retire SEO any more than answer engines retired search. It sits on top, and it rewards the sites whose foundations were already clean and well structured.

Building an agent-ready website: what to do now

The standard is early, but almost none of the preparation is speculative. It is sound practice regardless of how quickly WebMCP arrives.

Get the structured foundation right. Clean semantic markup, comprehensive Schema.org data and a clear information architecture are what every agent protocol builds on. A site that is already legible to machines is most of the way there.

Map your real tools. List the handful of actions a customer actually wants to complete on your site: get a quote, check availability, find a product by specification, retrieve a document, book a call. These are your future endpoints, and naming them is a useful exercise even before a line of code is written.

Treat your site as a product with an interface, not a brochure. The brands that win the agentic web will be the ones whose sites were built to be operated, with logic and data that can be exposed cleanly, rather than presentation layers with the substance buried inside them.

Design the governance first. Decide what may be called, by whom, how often, and how it is recorded, before you expose anything. The control model is not an afterthought here. It is the feature.

Pilot early, and watch the standard. The advantage in answer engine optimisation went to those who moved before it was common talk. WebMCP is at that same stage today. A small, governed pilot now is worth more than a flawless rollout in two years.

Risks, and the part most people will skip

Exposing tools to autonomous software demands the same discipline as exposing any API, and then some. Only the actions that should be callable should be callable. Inputs must be validated, because an agent will send you exactly what its schema permits and nothing it does not understand. Rate limiting and authentication matter, because a tool that can be called can be called at scale. And every call should be logged, both to debug and to demonstrate, after the event, precisely what happened. The businesses that treat WebMCP as a security and governance project, and not only a marketing one, are the businesses that will be able to use it.

Frequently asked questions

What is WebMCP?

WebMCP, the Web Model Context Protocol, is a proposed web standard that lets a website expose structured, callable tools to AI agents through a browser interface, navigator.modelContext. It effectively turns a website into an API that AI agents can use directly, rather than by scraping the page.

Is WebMCP the same as MCP?

They are related. The Model Context Protocol, or MCP, standardised how AI systems connect to tools and data, mainly on the server side. WebMCP brings the same model into the browser, so the website itself acts as the tool provider, often with no additional backend.

Does WebMCP replace SEO or AEO?

No. Search optimisation makes you discoverable, answer engine optimisation makes you citable, and WebMCP makes you actionable. They are layers in a stack, and WebMCP rewards sites whose search and structured-data foundations are already strong.

When should a business act on WebMCP?

The groundwork, clean structure and well-defined actions, is worth doing now because it pays off regardless. A governed pilot is sensible for any business whose customers are beginning to research or transact through AI agents, which increasingly means anyone selling into a considered, B2B or regulated market.

The shape of the next web

The web spent thirty years optimised for human eyes. It is now, quietly, being rebuilt for software that acts on a person's behalf. The question for any serious business is no longer only whether its customers can find it, but whether their agents can work with it, and whether the business can trust what happens when they do. For the industries we work in, where a single wrong specification carries real cost, that is a question worth answering early and carefully.

This is the kind of shift we help clients get ahead of: not chasing every trend, but building digital foundations precise and well structured enough that the next standard becomes an adoption rather than a rebuild. If the agentic web is on your roadmap, or you want to understand what an agent-ready version of your site would involve, it is worth a conversation.