WebMCP Explained: Letting Websites Publish Tools Instead of Agents Clicking UIs

Picture a small side project where an AI agent has to operate a web app by itself. The first version works the way most browser agents do: the agent gets access to the app and works things out from whatever the page shows. For a basic Todo app, the request might be "Add 'Buy eggs' to my list." To carry it out, the agent has to inspect the page, find the input box, work out which button submits the form, perform the click, and then check the result.

It works, but it feels like far too much effort. The app already knows precisely what should happen. A function sits behind that button, an API sits behind that function, and the operation itself is one clear call:

add_todo(title)

So why should the agent stare at the interface and guess how to do something the application can already describe? That's the point where WebMCP begins to make sense. The flow becomes something like this:

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

The interface is still there for human visitors. The agent just doesn't have to decode it to get an action performed. That shifts the framing of the whole problem. The question may not be how to make AI better at using websites. It may be how to make websites better at telling AI what they can do.

Two ways agents use the web today, and where each falls short

An agent that needs to act on a site currently has two common routes.

The first is browser automation. The agent takes screenshots, works out what's clickable, moves a cursor, fills in a field, clicks, checks what happened, and loops. It resembles watching a person drive a browser, and it has the same weaknesses: it's slow, it burns tokens, and it breaks easily. A tiny layout change, a menu that's hidden, a hover-only interaction, or a flow with an extra step can throw the agent off course.

The second route is a custom MCP server written for your application. For tools, that's a far better experience. The cost shows up elsewhere, because the agent must know the server exists and connect to it first. When every website ships its own bespoke integration, that doesn't scale. This is the practical ceiling of the custom-MCP approach.

That leaves a gap. Browser automation is too indirect, and custom integrations are too manual. WebMCP aims at the space in between.

What WebMCP actually is

Put simply, WebMCP lets a website announce to an AI agent, "here are the things you can do on this page." Rather than the agent wondering which button to press, the site hands over a list of actions.

An online shop, for example, could publish tools like these:

search_products()
get_product_details()
add_to_cart()

An agent browsing the site finds the tools on its own and calls them with the structured inputs each one declares. Nothing has to be registered inside the agent ahead of time. Tools are discovered dynamically from the website, and that's the part worth noticing. A site stops being only a pile of pages and starts offering capabilities.

A concrete example: the Todo app

Take a simple Todo application. With no WebMCP, an agent would need to inspect the page, find the input, type the text, locate the Add button, click it, and re-read the updated interface.

With WebMCP, the application can publish four tools:

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

The agent no longer needs any knowledge of the visual layout. It knows what the application can do. A demo built exactly this way showed a Todo app exposing four tools, with a connected agent reading their schemas and invoking add_todo straight away. Telling the agent to add "I have to buy eggs" to the list triggered the tool call, and the new item appeared in the app.

The mental model is much cleaner: the UI is for humans, tools are for agents, and both operate on the same application.

What a tool definition looks like

Here frontend engineers will find it interesting. The implementation in that demo registers tools through navigator.modelContext. Each tool carries a handful of parts:

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

The shape is consistent: a name, a description, an input schema, and an executor function that performs the work, typically by calling backend APIs the application already has. That last point matters. WebMCP doesn't ask you to rewrite business logic for AI. The existing application remains the system that carries out the operation, and the agent merely gains a structured way to trigger it.

The authentication catch

Things get serious once the app is no longer a toy. Imagine tools like these:

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

An unknown agent shouldn't be able to invoke those freely. A second demo in the same material tackles exactly this with OAuth. The WebMCP tools sit on top of an authenticated application, and users who haven't signed in can't run the protected actions.

This matters because agents arrive from many kinds of clients: an AI-enabled browser, a desktop agent, or another agentic app. A standard mechanism such as OAuth makes the capability layer far easier to protect across all of them, compared with inventing a login flow for every integration. Once sites expose capabilities to agents, authentication becomes part of the agent experience from day one and not a patch added later.

A new question for frontend design

For years, frontend architecture has revolved around one chain: interface, state, API, backend. WebMCP adds another question to ask: which capabilities should this application expose to an agent?

It sounds minor, but it could change how features get designed. An "Add to cart" button is a human interaction. This call is an application capability:

add_to_cart(productId, quantity)

Both may eventually get designed together. People get a polished interface, agents get a structured capability interface, and both end up in the same business logic.

It isn't only about speed

There's a deeper reason this matters than faster agents. When an agent works through screenshots and clicks, the interface itself is the contract, and any change to the interface can break the agent. With WebMCP, the tool definition becomes part of the contract.

That drags a new set of things into a frontend developer's scope: tool names, descriptions, input schemas, execution behavior and authentication boundaries. The job stops being only about designing screens. It starts to include designing how software presents itself to intelligent systems.

Still early days

One caveat deserves emphasis. WebMCP remains an early-preview proposal and not a settled web standard. The demo ran in Chrome Beta with WebMCP switched on via browser flags, and the presenter stated outright that the API could still change. Rebuilding production architecture around it right now would be premature. Experimenting with it is a different matter, because the idea underneath is larger than today's API.

Websites have been built for decades on a single assumption: a human sits on the other side. WebMCP is one of the first experiments to challenge that. Web applications may soon have to answer two questions. How should a person use this? And how should an AI agent use it? The first question produced modern frontend engineering. The second may well shape what comes next.