For most of my career, I have built websites for humans. Humans can be annoying users, but at least I understand them. They miss buttons, ignore error messages, click the logo to go home, and press Submit three times if nothing happens within half a second.
A few days ago I was listening to Syntax episode 1037, WebMCP is here (and you should care), where Wes Bos and Scott Tolinski talked to Sarah Drasner and Dominic Farolino from the Chrome team.
I had heard the name WebMCP before, but I had not paid much attention to it. Listening to them talk about it made me think about something I had mostly ignored until now: websites are starting to get a new kind of user.
The AI agent.
Not another person using an AI assistant alongside the website. Software actually trying to use the website on that person's behalf.
That changes a few assumptions I have had about frontend development for a long time.
The awkward way agents use the web today
Imagine telling an agent:
Find me a hotel in Edinburgh next Friday for under £180, with parking, and book it.
Today, an agent might open a hotel site, find the date picker, enter the dates, wait for the results, set a few filters, inspect the rooms and eventually find the booking button.
The fact that this works at all is impressive.
But from a software point of view, it is a strange route to take.
Behind the date picker there is probably some logic that accepts a check in date and a check out date. Somewhere behind the booking button there is an action that takes a room, some customer details and a payment method and creates a reservation.
The agent does not really care about the date picker or the button. Those exist because humans need an interface.
What the agent needs is much closer to this:
searchHotels(...)
getRoomAvailability(...)
reserveRoom(...)
cancelReservation(...)It needs to know what the website can do, which inputs those actions require, and whether it is allowed to call them.
At the moment, we often make agents work that out by looking at the same interface we designed for people.
WebMCP gives the browser another option
This is where WebMCP got interesting to me.
It is still experimental, so I would not design a production system around it yet. But the basic idea is quite straightforward: a website can expose structured tools that an AI agent can discover and call.
Instead of an agent inspecting the page and deciding that a particular blue rectangle probably means "book this room", the site can explicitly tell it that a booking action exists and describe the data that action needs.
Chrome's current API lets sites register tools with JavaScript, and there is also work around exposing normal HTML forms as tools.
For a human, interaction still runs through the UI to reach a product capability. For an agent, it could increasingly go straight to the capability itself.
That does not make the UI less important. People still need to browse products, compare options, understand what is happening and decide what they want.
It just means the UI may no longer be the only way into the product.
Semantic HTML becomes useful in another way
Frontend developers have been told for years to use real buttons, label inputs properly, use headings correctly and stop turning <div> elements into buttons.
Accessibility is still the main reason to do that.
But the same work also makes a page easier for software to understand.
A button containing the text "Add to basket" has quite a lot of meaning attached to it. A clickable <div> containing several nested spans, an SVG and a collection of generated CSS classes has much less.
WebMCP goes further by letting the site describe actions directly, but it feels like part of the same general direction. The more meaning we put into the things we build, the less another system has to guess.
It also changes how I think about frontend architecture
Take a shopping site.
A person might open the filters and choose waterproof, size 10, under £120, then sort the results by delivery date.
An agent might receive:
Find me waterproof walking boots, size 10, under £120, that can arrive by Friday.
The goal is the same. The route through the product is not.
This makes the boundary between what the product can do and how the current interface happens to expose it more important.
We already know that business logic should not live inside random React components. In practice, though, it is very easy for product behaviour to slowly become tied to the UI that happens to trigger it.
If addToBasket() only really works when it gets called from ProductCard.tsx, that is already a design problem. Having another type of client trying to call the same behaviour just makes the problem harder to ignore.
I can imagine this affecting how I structure frontend applications even if I never touch WebMCP itself.
The UI becomes one consumer of the product's capabilities rather than the place where those capabilities live.
Actions are where this gets complicated
Reading hotel prices is one thing. Booking a £1,200 hotel is another.
As soon as agents can do more than read information, the difficult part stops being how they find the right button.
Now we have to think about what they are allowed to do.
Did the user actually ask for the action? Should the agent be able to complete it without confirmation? Which actions need extra approval? What happens if the agent chooses the wrong thing? Can the action be reversed?
WebMCP's security guidance already deals with some of this. Tools can describe whether an action is read only or consequential, and the guidance also covers indirect prompt injection, where content on a page tries to influence an agent into doing something the user never asked for.
I think undo becomes especially useful here.
If software is going to do more things on my behalf, I would much rather have a clear history of those actions and a reliable way to reverse them than approve every tiny step before it happens.
That part of the experience feels just as important as exposing the actions in the first place.
We probably do not need a new web
I do not think every company suddenly needs an "Agent Experience" team.
WebMCP is experimental. The API will probably change. It might become widely used, or another approach might end up solving the same problem.
But I think the underlying shift is worth paying attention to regardless of what happens to WebMCP.
Some people will increasingly interact with products through software acting on their behalf rather than by manually clicking through every part of the interface.
A lot of the things that make a site easier for agents are things we should probably be doing anyway: semantic HTML, clear boundaries between UI and business logic, well defined product actions, and careful handling of anything that changes data or spends money.
For most of my career, the frontend question has been:
Can a person understand how to use this?
We may increasingly have to ask:
Can software understand what this product is capable of doing?
I think that is a far more interesting frontend problem than finding another way to style a button.