“Find a room for two people for two nights next Friday. We’d prefer a sea view and breakfast. Ask me before booking.”
A straightforward request. Yet fulfilling it on a hotel website can involve working through several pages, negotiating a calendar, comparing rooms, selecting extras and checking what the price actually includes.
We have become accustomed to this translation work. We arrive with an intention and turn it into whatever sequence of clicks the website requires.
Ask an AI assistant to do the job and, if it can operate a browser, it may follow much the same route. It examines each page, identifies the controls, enters the details and works out what to do next.
But suppose the website could explain itself:
I can check room availability. Tell me your dates and how many people are staying.
That is the idea behind WebMCP. A website can describe useful actions in a form an AI agent, an assistant able to carry out tasks, can understand and use.
The interesting part is what this could change about our relationship with websites.
A little like alt text, but for actions
If you have ever added alt text to an image, the basic idea may feel familiar.
Alt text is a written alternative to an image. It helps someone using a screen reader understand what the image communicates without having to see it.
The useful principle is simple: make the meaning explicit.
WebMCP applies a similar idea to the working parts of a website. A booking form can explain what it does, what information it needs and how an agent can use it.
The analogy only goes so far. Describing a photograph and making a booking have very different consequences. But it gives us a starting point:
What is this? becomes What can I do here?
And the visible website need not look any different.
More like a conversation with the website
Return to that hotel booking.
On an ordinary website, the agent may have to click through the journey, interpreting each page much as a person would. With WebMCP, the interaction can be more like a conversation:
Website: “I can check room availability. Give me your dates and the number of guests.”
Agent: “Two adults, arriving on Friday and leaving on Sunday.”
Website: “Here are the available rooms, their prices and what’s included.”
Agent: “Select the sea-view room and include breakfast. Show the total price and booking details so the customer can review them before confirming.”
This is an illustration, rather than a literal chat. Underneath, the agent sends structured requests and the website returns results. The website describes the actions it offers, and the agent works out which ones will help fulfil the customer’s request.
Developers call these actions tools. A tool might search for rooms, add breakfast to a selection or produce a booking summary.
There are three participants here. You explain what you want. The agent chooses an appropriate action. The website performs that action using its own systems.
The agent still has some thinking to do. It may need to clarify which Friday you mean or whether a sea view is essential. But the website has given it an explicit way to proceed, reducing the need to work everything out from the page.
For a straightforward form, a developer may be able to add the necessary descriptions to what already exists. More involved tasks require additional code connecting the agent’s request to the website’s functions.
The organisation does not necessarily need to build its own AI assistant. It can make its service easier for a customer’s chosen assistant to use, provided the browser and assistant support the approach.
How real is this?
WebMCP is experimental, with contributions from people at Google and Microsoft and development taking place through a web standards community. Google’s Chrome browser offers a way for developers to try it.
It is still a proposal. It has not become an established web standard, and support cannot be assumed across browsers and AI assistants.
That makes it useful to explore, while leaving plenty of room for its details and its eventual importance to change.
There are other ways for agents to use services. They can operate the ordinary website. They can connect to an API, a route through which software exchanges information and requests actions. They can also use MCP, short for Model Context Protocol, which helps AI applications connect to external tools and information.
WebMCP brings a related idea into the web page itself. These approaches can coexist, and an agent could use different ones for different tasks.
The bigger development is that organisations are beginning to consider how their services should work when a customer delegates some of the interaction to software.
What does “book” actually mean?
That hotel request sounds clear enough. Yet it contains several decisions.
Is the sea view essential, or would you accept a better room without one? Is breakfast included in the quoted price? Does selecting a room reserve it temporarily? At what point do cancellation charges apply?
These questions belong to the hotel’s service as much as to its technology.
A well-designed journey would let the agent find suitable options and present the full price and relevant terms. It would also make clear whether anything had been reserved, paid for or confirmed.
WebMCP includes ways to flag actions with significant consequences, which can help an agent or browser decide when to ask for approval. The service still needs to enforce its booking rules and permissions. Adding a description does not settle those decisions.
That is where some of the most important design work lies: deciding how far the agent can go, what the customer needs to see and when control should return to them.
A successful interaction should leave the person knowing exactly what has happened.
Start with what the customer wants to achieve
For organisations considering this, the first useful conversation is about their service.
At a visitor attraction, an agent might help a family find a suitable visiting time, check access information and choose the right tickets.
At a retailer, it might help someone describe what they need, compare suitable products and check stock without first learning the shop’s categories.
For a museum, a teacher might want objects related to a lesson topic, with reliable descriptions and clear permission to use the images.
For a ferry operator, a traveller might need a sailing that can accommodate their vehicle, an update on disruption and an alternative if their preferred crossing is unavailable.
Each example starts with something a person wants to accomplish. The technology comes later.
Take one of those journeys and describe it in ordinary language. What information is needed? Where does the reliable answer come from? What choices can the agent make? What needs the customer’s approval? What should happen if there is no suitable result?
Those questions often expose gaps that already affect people using the website themselves.
If nobody can clearly explain whether a price includes breakfast, an agent will inherit the confusion. If access information is incomplete, a more efficient search will not make it complete.
Preparing for agents can become a useful exercise in understanding the service you already provide.
Keep the process clear and the technology open to change
There is an understandable temptation to wait for a winner. Which browser, model, platform or protocol will become the safe choice?
Technical decisions can bring years of cost and commitment. But there is useful work to do before making a large investment.
Agree the customer outcome. Describe the process and business rules. Establish where human judgement or approval matters. Decide how you will recognise a successful result.
That gives an experiment something concrete to deliver and a future implementation something to preserve.
AI-assisted development may make it quicker and cheaper to build a small prototype or adapt part of an existing service. The savings will vary, and testing, integration and maintenance still matter. But a clearly defined task gives a team a better basis for trying something, learning from it and changing direction.
A room search is a manageable experiment. Rebuilding an entire booking operation around an emerging technology is a much larger commitment.
The durable investment is the understanding of the service: what it should do, for whom, under which conditions and with what result.
That understanding remains valuable if the technology changes.
What happens to the website?
If agents take on more of the clicking and searching, website design acquires some interesting questions.
Where does the customer encounter the information that helps them choose? How do they review what the agent has found? How do they correct a misunderstanding or take over midway through a task?
The interface still has work to do. It may become the place where someone reviews a shortlist, understands a trade-off or approves a decision, while their agent handles some of the steps around it.
Over time, booking platforms could provide ready-made agent tools. Organisations might ask for important customer journeys to work for both people and their assistants. Familiar conventions could emerge for searching, comparing, selecting and confirming.
Those are possibilities, rather than a settled picture of the next web. WebMCP is one experiment that helps us see them more clearly.
A useful first step is modest: choose an important customer journey and ask what someone’s agent should be able to achieve there. Describe the answer without naming a technology.
You may discover that the most valuable preparation is something your service needed anyway.
Alt text gives us a familiar example of making meaning explicit. As software takes a more active role in using websites, their capabilities may need the same care and clarity.
“What can I do here?” is becoming a question worth designing for.
Sources and further reading
Technical status checked on 14 September 2026. WebMCP is experimental and its specification and support may change.