The short version

For thirty years websites have been built for people with eyes and a mouse. An AI agent sent to one has to pretend to be that person: read the screen, guess which box is the search box, guess which button submits, and hope. It works until the site changes its layout, and it has no way of knowing that one button says "Save" and the next one says "Delete everything".

WebMCP turns that round. The site publishes a short list of things it can do, in plain language, and the agent picks one. Book a table. Check stock. Start a return. The site stays in charge of what is on the list and what happens when something is chosen.

The name comes from MCP, the Model Context Protocol, which is how AI systems already talk to software behind the scenes. That needs a server somebody builds and runs. This needs nothing but the web page a visitor is already looking at.

Who made it, and why now

It was proposed by engineers at Google and Microsoft, and it is being worked on in the open at the W3C, the body that standardises the web. It is a draft, not a finished standard.

The why is not complicated. Every large AI company is now shipping something that browses on your behalf. All of it currently works by looking at pixels and guessing, which is slow, expensive and fragile. The companies building those agents and the companies running the browsers are the same companies, and they would rather websites simply said what they can do.

What it looks like in practice

Four examples, none of them hypothetical, all taken from what is being demonstrated today.

Booking something. You tell an assistant to book a table for four on Thursday. Instead of driving the restaurant's website like a person, it calls the restaurant's own "book a table" action with the date, the time and the number of people, and the restaurant's site does what it always does.

Filling in a long form. Insurance, a mortgage application, a customs declaration. The site says which fields exist and what each one means; the agent fills what it knows and leaves the rest for you, without ever clicking the wrong thing.

Customer support that can actually act. "Where is my order" stops being a search through a help centre and becomes a call to the shop's own "look up my order" action, in your session, with your login.

Internal tools. This is the one most businesses will feel first. A company's own dashboards, admin panels and back-office systems are exactly the kind of software people hate using and agents are good at driving. They are also behind a login, where a public API was never worth building.

The real change is speed

Today an agent has to load your page, draw it, look at it, guess, click and start again. Every step is seconds, and every step costs money. That is why agents run small, careful errands and nothing more.

A direct call takes milliseconds, and it works both ways: it asks and your site answers, it hands over details and your site takes them. No screen in the middle translating for a pair of human eyes.

A website stops being somewhere a person visits and becomes something other software works with, at machine speed. That changes what is worth asking a website in the first place.

What it is not

This part matters more than the features, and most of what has been written about it gets it wrong.

It is not a way to be found. No search engine can see these actions. There is no directory, nothing in a sitemap, nothing to submit anywhere. An agent only discovers a site can do things by being on that site already. Publishing them will not get you into ChatGPT's answers, will not get you into Google's AI Overviews, and will not bring you a single visitor. That work is still done by good content, clean structure and the machine-readable versions of your pages.

It is not an open door to your systems. It runs inside one visitor's browser tab, in their session, as them. It is not a public interface, and the design assumes a person is sitting there.

It is not finished. Chrome is running a trial of it through 2026. No other browser has it. Anything built on it today is built on a draft, and parts of it will change.

What it signifies

Strip out the detail and one thing is left: the web is getting a second audience.

For three decades the only question was how a page looks and reads to a person. The answer now has a second half: what can a machine do here, and how does it know. Sites that answer that question will be usable by the assistants people are starting to delegate to. Sites that do not will be scraped, badly, or skipped.

That shift is worth watching whatever happens to this particular specification. WebMCP may not be the one that wins. Something with its shape will.

What it changes

  • Sites whose only goal is "contact us" will fade. If the answer to every question is a form, there is nothing for an agent to call, and it moves on to a site that answers.
  • Traffic stops being demand. At best it becomes a marker for it, and not a reliable one. Visits will fall, and the number of conversations you have with an actual person will fall with them.
  • You will design a second experience, for agents. Not a version of the human one. A different flow, with different steps, for a visitor with no eyes and no patience.
  • Things that were not worth doing become easy. Real search inside a shop. Genuine comparison of a product across sellers. Work that was always possible and never worth the tedium.
  • Original material matters more, not less. When everything generated sounds the same, what a machine cannot assemble from your competitors' pages is the only thing left that is yours.
  • Integration stops being a project. A site with these actions is close to an open interface that already works. The cost and the time of connecting two systems fall hard, and a lot of middleware stops being worth paying for.
  • You will be persuading agents. They act for a person, but they are the ones shortlisting. Almost everything marketing knows assumes a human reading. That assumption is about to be half wrong.
  • Not every agent is friendly. Some will be pointed at you deliberately. That belongs in the design from the first day, not bolted on after something happens.

The dangers, plainly

An agent reads instructions from whatever it is looking at. If a website's description of what it can do is written by someone untrustworthy, or if the text an action returns includes something a stranger wrote, a review, a comment, a shared document, the agent can be talked into doing something nobody asked for. This is a real and well-documented class of attack, and the draft names it as the central risk.

Convenience and consent pull in opposite directions. The whole point is that the agent does not stop to ask. The whole point of safety is that it stops to ask before anything that matters. Where that line sits is a decision each site makes, and plenty will put it in the wrong place.

Doing too much, too early. The temptation is to expose everything, because it is easy. The right instinct is the opposite.

Do and do not

Do start with actions that only read: what you sell, what it costs, where the order is, when you are open. Nothing there can be abused, because nothing there changes.

Do keep a person in the loop for anything that spends money, sends a message, deletes something or changes an account. Let the agent get everything ready; let a human press the button.

Do treat the descriptions as writing. They are what the agent reads to decide what to call. Vague ones get ignored; careless ones cause the wrong thing to happen.

Do not sell it internally as marketing. It is not going to bring traffic, and promising that it will is how a sensible project gets cancelled in six months.

Do not expose anything you would not let an unattended script do at three in the morning.

Do not rush it. The audience today is very small. There is no penalty for being second here, and there is a real penalty for being first with something insecure.

So should a business do anything about it?

For most, not yet. Almost nobody can use it, and nobody is winning customers with it in 2026.

Two exceptions are worth naming. If your product is software that people spend hours inside, the day agents can drive it is the day your competitors' customers start asking why yours cannot. And if you sell AI work, a site that can be driven by an agent is the cheapest possible proof that you can build one, which is a better argument than a case study.

Everyone else should understand it, watch it, and not spend money on it this year.

Where to read the actual specification