AI Engineer Europe 2026
The agent-ready web: Simplify user actions with WebMCP
Read the talk
The agent-ready web: expose actions with WebMCP
WebMCP lets websites expose structured tools to browser agents, turning ticket purchases, form submissions and other UI workflows into explicit calls that users can follow.
From a talk by Tara Agyemang
Before you start: Basic familiarity with HTML forms, the DOM and JavaScript will help with the implementation examples.
Two tickets, too much inference
Buying two concert tickets should not require reverse-engineering a website. Tara Agyemang, introducing herself as a developer relations engineer on Google’s Chrome team, starts with a concert site she built: BeatDrop. A user opens Gemini in Chrome beside the site and asks for two tickets to the Afrobeats Festival. The goal is straightforward; discovering how to carry it out is the expensive part.
An agent might parse the entire DOM, inspect the accessibility tree, and take a screenshot to understand elements those representations did not resolve. It then has to locate the target, work out where to click and perform the action. After all that inference, an advertisement can finish loading at the top of the page, push the content downward and invalidate the calculated coordinates. Agyemang describes the process as brittle and potentially token-heavy, without measuring its token cost.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make the page usable, then expose its capabilities
The first improvements are ordinary web engineering: semantic HTML, robust accessibility, fast page loads, attention to Core Web Vitals and clear user journeys. These make the site easier for people to use and give agents a better representation to work with. WebMCP builds on those foundations. It does not remove the need for them.
Web Model Context Protocol, or WebMCP, is a proposed web standard for describing a site’s capabilities as structured tools. Instead of making the agent infer which combination of controls performs an action, the site supplies a menu of available actions. Agyemang invokes the USB-C analogy: a common interface through which agents can discover what a website supports. She reports improved performance and reliability, but supplies no numerical benchmark or measured token reduction. The mechanism is the important part here: an explicit action contract reduces the work of interpreting the interface.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Discovering and calling tools in Maze Escape
Chrome DevRel’s Maze Escape makes that contract visible. The Model Context Tool Inspector runs in a Chrome extension side panel and lists the tools exposed by the current page. It offers both natural-language prompting and direct tool invocation; this demonstration uses prompting. The Inspector is a development extension, separate from the Gemini in Chrome panel in the opening example.
The maze is deliberately unusual: clicking around its UI cannot navigate it. It is controlled through AI tooling. Initially, the Inspector discovers only the tool for starting a maze game. With Gemini 2.5 selected, Agyemang asks to start a game. The agent calls the start tool, receives its result and uses that returned information to compose a response. A maze appears on the page.
Starting the game also changes the available tools. The new page exposes movement in the north, south, east and west directions; inspection of the current location and open directions; and tools to pick up, drop and use items. The available actions follow the current page’s state. An agent does not have to work from one global, unchanging list of everything the application might do.
A request to move down and then right becomes calls to the movement tool with the corresponding cardinal directions: south, then east. The next example uses shorthand, including R, which the agent interprets as right before calling the same tool. Natural language supplies the intent; the tool supplies a constrained way to act on it.
A broader instruction—“Complete the maze”—lets the agent repeatedly choose among movement and item tools. But explicit tools do not automatically produce a good plan. Agyemang observes that this prompt can send the agent backward to the start before it moves forward again. Supplying the location of the exit, in the bottom-right corner, gives it a more useful direction. She stops the demonstration before the maze is completed because traversal can take a while, then points viewers to the Inspector’s Chrome Web Store listing.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Expose a form with the declarative API
WebMCP proposes two implementation approaches. The declarative API starts with a standard HTML form: add toolname and tooldescription, and the browser generates a JSON schema whose parameters come from the form fields. The form already describes the inputs; the extra metadata tells the agent what the action means and when to use it.
The talk also introduces agentInvoked as a way to distinguish agent involvement. More precisely, the declarative API defines it as a Boolean property on SubmitEvent, indicating agent-triggered submission. It is not an HTML attribute that records who filled every field. For ordinary forms, the declarative approach keeps the tool definition close to the interface that people already use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Register custom actions with JavaScript
For more complicated or multistep UI flows, the imperative API lets the application register its own tools. registerTool receives an object containing a name, description, manually authored input schema and execution function. The description matters because the agent uses it to decide when to call the tool—not merely to label it in a list.
The execute function runs ordinary JavaScript. It can be a light wrapper around functions the application already uses. In the talk’s addTodoItem example, execution validates and trims the input, creates DOM nodes and adds the item to the page. The following version expresses that pattern using the imperative API documented in August 2026, with document.modelContext.registerTool; it is not a transcription of the earlier slide.
javascript
const list = document.createElement('ul');
list.setAttribute('aria-label', 'Todo items');
document.body.append(list);
document.modelContext.registerTool({
name: 'addTodoItem',
description: 'Add one non-empty task to the visible todo list.',
inputSchema: {
type: 'object',
properties: {
text: { type: 'string', description: 'The task to add.' }
},
required: ['text'],
additionalProperties: false
},
execute: async ({ text }) => {
if (typeof text !== 'string' || !text.trim()) {
throw new Error('Task text must not be empty.');
}
const task = text.trim();
const item = document.createElement('li');
item.textContent = task;
list.append(item);
return {
content: [{ type: 'text', text: `Added task: ${task}` }]
};
}
});
The same operation changes the visible list and returns an outcome to the agent. That returned information lets the agent determine what happened and choose its next step; changing the DOM alone would leave that feedback implicit.
Agyemang expects the imperative approach to be the more commonly used option because many applications have workflows more complex than a standard form. The practical choice follows the existing interaction: expose a form declaratively when it already captures the action, or register a custom tool when the application needs to coordinate more behavior.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A ticket purchase through three tool calls
Back on BeatDrop, the site now exposes tools alongside its featured events, full event listing and individual concert pages. Agyemang selects Gemini 3.1, saying it has worked better for this particular demo in her experience. This time the request is for two VIP tickets to the Summer Vibes Festival.
The agent carries the request across page boundaries:
searchConcertssearches by the concert name and returns information including the concert ID.openConcertPagetakes that returned ID and opens the Summer Vibes Festival page.- The new page exposes a purchase tool, described in the narration as
purchaseTicket. The agent calls it with quantity2and the VIP section.
The demo displays a purchase notification reporting £356 spent. Agyemang jokes about putting it on Google’s credit card; this is the demo’s reported outcome, not evidence of a real payment.
Tool calls must keep the visible UI synchronized. The user can see the concert page open, VIP become selected and the quantity update. For a real purchase, Agyemang recommends handing the final checkout step back to the user so they know they are spending money. Preparing a purchase and authorizing payment should remain distinguishable in the interface.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Try the experimental workflow
The recording presents WebMCP in early preview, with an API changing quickly enough that the displayed code might differ the following week. The purpose of trying it is to discover useful interaction patterns and report where the API gets in the way.
Agyemang’s setup sequence is:
- Use a separate Chrome Canary installation for experiments. She gives Chrome 146 and later as the browser baseline at the time of the talk.
- Enable the WebMCP testing flag through the browser’s flags interface.
- Install Model Context Tool Inspector to discover, invoke and debug the page’s tools.
Those historical requirements differ from the August 2026 setup: the current Chrome guide describes an origin trial beginning with Chrome 149, while Inspector version 1.9.13 requires Chrome 150.0.7861.0 or later. The Inspector also warns that it lacks production security boundaries, so use it only on trusted sites.
The early-preview announcement is the entry point Agyemang recommends for program signup, initial documentation, best practices and API details. The WebMCP tools repository contains the Inspector, the maze source and other demos. She describes roughly six or seven demos at the time, plus an evals CLI for testing a site and its exposed tools. The next step is to exercise those tools against real user goals, then report friction and bugs so the API can improve before reaching more users.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make site actions explicit
Agents are already using the web. Making them repeatedly reconstruct actions from screenshots and page structure need not be the only interface available. WebMCP’s ambition is to let a website function as a high-performance API for agents while preserving a useful, visible experience for people. The invitation is to make the site’s capabilities explicit, try them with an agent, and keep the person’s experience central as those actions become easier to delegate.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Chrome's announcement introduces structured website tools, the two API approaches and the early-preview program.
Developer utilities, evaluation tooling and example applications, including the agent-controlled maze.
Chrome extension for inspecting and invoking tools manually or through Gemini. Requires the documented browser version and testing flag; use only on trusted sites.
Further reading
- WebMCP proposalRepository
Design rationale and ongoing discussion of browser-native tools and collaborative browsing.
Updates since the talk
Public setup instructions, origin-trial information, limitations and guidance for testing agent interactions.
Expose HTML forms as tools and handle agent-triggered submission and results.
Register JavaScript tools and manage execution, cancellation and tool lifecycles.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hello.
- 0:15
Hello. Hello. Can you hear me okay? Yes. Okay, cool. Let's get started. So we are gonna be talking a little bit about WebMCP. Has anybody-- Just out curiosity, has anybody already played around with WebMCP?
- 0:32
Only a few people. Okay, great. Those few people, you have a bit of a head start, but for everyone else, we'll be going into a bit more of the background, how it works, what it does.
- 0:40
So my name is Tara. I am part of the Google Chrome team. Um, I'm a developer relations engineer, and I'm here with a few of my colleagues from Google Chrome alongside the DeepMind team too.
- 0:53
So we'd be really interested to talking to you afterwards around the DeepMind booth if you like have thoughts around web and AI and the intersection between the two. That is where my focus is these days.
- 1:07
So let's get into it. The, let's say, past few decades, we have been building the web for human actions and human eyes, and we've been trying to optimize for that.
- 1:21
But these days it's not just humans that are using the web. We have agents using the web on human behalf too, and we are seeing an increasing number of agents using the web.
- 1:35
But the problem is the agents are having to do so much work to do simple actions on the sites that we've built. And just to give you a bit of an example of this, this is a, a website that I've live coded, and it's a concert website for selling tickets for concerts.
- 1:55
And we have Gemini and Chrome panel on the side here. And let's say you've come along to this website, and you've typed this prompt. You want to buy two tickets to the Afrobeats Festival.
- 2:06
You've given it the details. The AI agent has to do so much work to make this happen. So it'll probably look at the HTML because usually the agents will parse the entire DOM just to understand what's happening on your page.
- 2:21
Then it will look into the accessibility tree just to understand the structure of your HTML page. Then maybe it'll take a screenshot of the page, analyze all the different elements that it couldn't see in the HTML and the accessibility tree.
- 2:34
And then maybe it will measure how far down it needs to click, how far across, where the exact element that it needs to click, and then it'll click that element.
- 2:43
And as you can see, this process is quite long. It can be brittle, and I don't even wanna guess at how many tokens you probably just used trying to do this.
- 2:51
It's probably a lot. And then after all that, maybe your ad has loaded at the top of the page, pushed all your content down, and your AI agent couldn't even click the right place in the end.
- 3:03
So there's so much to think about. But before we go into this proposed web standard, it's worth mentioning that you can do so much by improving web foundations first.
- 3:15
So making your site accessible for everyone makes it accessible to AI agents by default.
- 3:23
So if you improve your semantic HTML, if you focus on robust accessibility standards, and if you improve your page performance, make it load really quickly, think about those Core Web Vitals, and then improve really good user experience flows through your site, you're already halfway to getting an agent-ready website.
- 3:47
And it's only once you have those in place that it makes sense to start thinking about WebMCP.
- 3:53
So if you're not already aware, the Web Model Context Protocol is a, a proposed web standard, and that gives you the ability to define your site's capabilities as structured tools for your AI agents to use.
- 4:10
And so you might have heard references to this as the USB-C of AI agent interactions. And that's because i-instead of any agent guessing what your website does, you're kind of giving the AI agent a menu of tools that it can te- of tools that it can use and actions that it can take.
- 4:31
And so because of this, we're seeing that WebMCP significantly improves the performance and the reliability of agents navigating your website.
- 4:43
So let's see it in action. Hopefully Gemini treats me well today. So this is the Maze Escape game built by our team in Chrome DevRel. And just on the side here, we have a Chrome extension.
- 5:00
Um, I'll show you a link to that afterwards. But this is the Model Context Tool Inspector. And so we're using this. This is a standard Chrome extension that lives in your side panel, and it lists out all the tools that it finds on your website.
- 5:17
So at the moment, it only has one-- it can only see one tool, and that's the Start Maze Game tool. And then at the bottom down here, it gives you two options to interact with the page.
- 5:27
So you can interact via a prompt like a user would prompt normally via their AI agent, or you can call tools directly at the bottom, but we won't be looking at that one today.
- 5:40
So this specific maze game is actually more unique in that you actually can't browse it by clicking around the UI. You can only use this app with the AI tooling.
- 5:55
So let's start a new maze game here. You can also choose your model on the side. So let's stick with the Gemini 2.5. So you'll see that at the bottom when you send a prompt-
- 6:10
It gives you all the information. So the new pro-prompt to start a new maze game, and the AI agent, Gemini in our case, has called that tool Start Game.
- 6:20
The tool itself has returned this information, and then the AI has read that and given me this response. And so now we have our maze, and you'll notice that on this page we have a bunch of new tools in the scope of this page.
- 6:38
Whereas the previous page only had that one tool, this page we've got a bunch of tools to help us navigate the maze. So in this maze, you can move around with the north, south, east, west directions.
- 6:52
You can look to see where you are in the maze and which directions are open, and then you can pick up items, drop items, use items as you navigate this maze.
- 7:03
And if I pop in some prompts, I can see that I can move down, then maybe after that, then right.
- 7:16
The AI agent should use my prompt, match it to the specific tool, so in this case, the move tool. It's taken my direction of down and right, matched that to the north, south, east direction, and sent that off to the tool that we have registered on this page, and then it's moved it down and right.
- 7:40
And so you can do... And because it's an AI agent, it can understand a whole bunch of different things. So I could just say right,
- 7:48
up, maybe right again. Let's try that. And so the AI agent has seen that R stands for right, mapped that to the direction, and then called the move tool with those information.
- 8:03
And because it's an AI agent, it can just keep repeating the same tool, tool calls until it thinks that it's done what needs to be done. So I could even say, "Complete the maze."
- 8:17
And then the AI agent should use all the tools available to just keep moving around the maze, to pick up items, to use the items when it needs to, because it has all the information in the tools available.
- 8:29
This specific prompt was not the most efficient, so sometimes you'll see it'll go backwards all the way to the start and then go forwards again. But the more that you refine the prompt, the better the agent knows how to complete the maze in the most efficient way.
- 8:42
For example, if you just say, "The exit is in the bottom right corner," it'll be more efficient in its, uh, instructions to get to that, to that direction.
- 8:53
So I won't, I won't continue this 'cause it can take quite a while to complete this maze. But if we go back to the slides here.
- 9:08
So this is the Model Context Tool Inspector that I mentioned. So this is the web extension that our team in Chrome DevRel built. The QR code there is, is if you want to see where that is in the Chrome Web Store, but anyone can use that and grab it from the Web Store.
- 9:26
But essentially, WebMCP kind of unlocks this new approach to using the web, where your users don't have to spend a lot of time trying to figure out how to use more complicated sites, and they can figure out their own workflow.
- 9:40
So they can choose to browse your website the normal way for a bit, then they can hand over control to their AI agent, and the AI agent takes steps on their behalf.
- 9:50
And then your user can come in at any time to take control again and browse your site again the way they normally would. And so that ability to simplify user journeys and make those user journeys for people easier has been a large part of the reason we've seen interest and excitement in this new standard.
- 10:12
So I want to pause for a minute just to address the question that some people have, and that's: what is the difference between WebMCP and MCP? But you can kind of see them as being complementary to each other.
- 10:27
So whereas WebM-- so whereas MCP enables AI agents to connect to applications on the server side, and you'd need to set up your own server for the agent to access, and then the agent can access the information anywhere, at any time, WebMCP is different in that it's kind of inspired by MCP.
- 10:48
I like to think of it of as how JavaScript is inspired by Java, and that's, in short, WebMCP is the implementation of the tools part of the MCP.
- 11:00
And so WebMCP allows engineers to provide tools to in-browser AI agents, and it's very specific for the client-side features. So you have to have your browser window open for WebMCP to work, and then you can use it to help your agent interact with the browser.
- 11:20
So all of the tools live in the browser.
- 11:23
But you can imagine this for quite a few different types of use cases. So imagine those websites that are really complicated, they have a lot of steps that a user needs to take, maybe like booking a flight or filtering products on a normal shopping website, or filling in complicated medical forms or financial forms, or to trigger fixes
- 11:48
that need to be hidden on a page, that are hidden on a page.
- 11:54
Or if you're like me, you're just on a normal shopping site, and you're trying to find the right black faux leather clutch bag that can fit your mobile phone in, and instead of going through all the little filters, you just wanna ask your AI agent to do it for you
- 12:12
So these are a bunch of examples where any user can ask whatever AI agent they are using to complete these things on their behalf, so the user doesn't have to manually do this, and they don't have to fill in each input, they don't have to select each checkbox.
- 12:27
And using WebMCP in these cases can mean that you can make those actions much easier for users.
- 12:35
So let's look at the APIs. WebMCP proposes two approaches for implementation.
- 12:41
So we've got the declarative API and the imperative API. Let's start with the declarative API. So if you have a normal HTML form, you can just add a few attributes to the HTML to get this to work.
- 12:56
So we've got the tool name and tool description here, and then your browser will automatically generate a JSON schema that the agent can use to read using the form fields as parameters for the tool.
- 13:11
So here's an example of what the JSON schema would look like for this form HTML. And there are a whole b-bunch of other attributes that can be used. So there's like, um, an agentInvoked Boolean attribute, so you can tell whether your form was filled in by an agent or if it was filled in by a human.
- 13:28
And there's lots of, like, more specific, um, attributes that can be used for things like that too. But essentially, you wanna use the declarative API when you have a standard form element.
- 13:41
But when you have something more complicated, that's when we wanna go back to the imperative API. So this is where you can register and define your own custom tools for when you have more complex, maybe multi-step UI flows.
- 13:56
So here is an example. So at the bottom, we have this registerTool function,
- 14:02
and when you call registerTool with an object like this,
- 14:07
you need to manually create your own schema similar to the one that we had in the declarative API that was generated.
- 14:15
You name your tool and give it the description, and you wanna make sure you have really descriptive descriptions that enable the AI agent to know when it should be calling this tool.
- 14:28
And then you have the execute block, which is essentially where you call normal JavaScript. Maybe you already have functions that you're using that you can call in here, maybe do a light wrapper.
- 14:41
In this addTodoItem example, you can, like, validate and trim text input, for example, and then you create the do- DOM elements or DOM nodes and add them to your page.
- 14:53
And then you wanna return some information to the AI agent so it knows what's happened, if everything happened successfully, so it can use that information for its next steps.
- 15:04
So those are the two APIs. The imperative API is probably the one that's most used because people have more complex U- UI flows that it wants the agent to complete.
- 15:17
But if we go back to my Vibe Coded demo,
- 15:22
I have added a few tools here. So we have a few featured events in the demo, and then all of the events available down here, and then you can go in and purchase tickets for an ind- on an individual concert page.
- 15:48
So I have noticed that this works much better with Gemini 3.1, so I'm gonna try that one.
- 15:56
If we wanted to buy tickets to one of these festivals... Let's buy tickets to the Summer Vibes Festival.
- 16:07
Summer Vibes Festival. Uh, let's say two VIP tickets, because VIP only for me.
- 16:22
Send that prompt. So the A- the AI saw the tool searchConcerts,
- 16:30
which it has called to find the specific concert via the concert name, and the tool returned the information about the concert, including the ID for that concert. Then it has called the second tool, openConcertPage, with the concert ID,
- 16:50
and that has opened this Summer Vibes Festival page. And then this new page has separate tools. This one here called purchaseTicket, and it's called that in the third tool call here with a quantity two and the section name.
- 17:05
And then we've got a little notification to say, "Oh, you've bought your tickets. You spent £356." Great. I'll put that on Google's credit card. [audience chuckles]
- 17:16
But you can see as well, like, in each step, it's updated the UI to make sure the user can also see what's happening. So you also... You always want to make sure that your UI is in sync with the tool calls that are happening.
- 17:29
So we've got the VIP selected, we've got the quantity selected, and then it-- in real life, it would go through to some checkout page. You'll probably want your user to manually do that step, so they know that they're spending real money.
- 17:44
Let's head back. So if you're interested in trying this out, it's probably worth just understanding the status of where we're at with WebMCP. So we're still in early preview stage.
- 17:56
This API is very experimental. It will change. It has been changing over the past few weeks, and so the code that I've shown might be different next week. But that's because we want people to try it out.
- 18:10
We want feedback. We want to know the best way to use this API. And if you're interested in doing that, these are a few steps to get set up.
- 18:21
So WebMCP is enabled in Chrome version one four six upwards. I recommend using Chrome Canary just so you can keep things separate. Otherwise, in the normal Chrome, you have to enable experimental flags, and you might not want to do that on your normal, your normal browser.
- 18:41
Once you have Chrome Canary, you'll need to enable the WebMCP testing flag with... by putting this flag in your URL, and then install the Model Context Tool Inspector ex-extension from the Chrome Web Store that I mentioned earlier, just so you can play around and debug and see what your tools are doing.
- 19:03
Then, uh, these are the two resources that I recommend taking a look at. So this is our main blog post that gives you information on the early preview program for WebMCP.
- 19:16
So if you sign up there, you get access to all of our initial documentation, and you get extra information about the program, information on best practices, implement all the extra imple-implementation details that you, you might want to use while you're testing it out, and all of the API information.
- 19:36
That is the first one, and the second one is the GitHub repository of all the tools. So we've got the inspector tool here. We've got all the demos, so you can see the maze demo code is live there for you can-- to play around with.
- 19:50
There's about six, seven different demos you can try out, and there's an evals CLI tool you can use to help you start testing your own sites in the WebMCP tools on your own sites today.
- 20:05
So I mentioned we're still in early preview. That's 'cause-- and we're looking for feedback. So try it out. Let us know what you think, if you have any friction points, if you find any bugs.
- 20:18
We'd love to know that so we can keep iterating on this API and eventually move on to the next stage and start getting WebMCP in front of more users.
- 20:29
But to wrap up, AI agents are already using the web. We don't have to settle for these token-heavy, brittle
- 20:42
screen-scraping processes that we have today. Instead, we can use WebMCP tools to turn every website into a high-performance API for agents and at the same time build incredible user experiences for the users of our sites.
- 21:02
So now that you have the tools and the context, please give it a go and try making your agents-- try making your websites agent-ready today. Thank you very much. [audience applauding] [outro jingle]