Build your website for the agentic era

Added: 2026-05-23

[00:00:01][music] Hello everyone. [laughter] Good to see you.

[00:00:12]>> Yeah, I think it's obvious, but are you having fun on IO? [laughter] Fantastic. Good to hear that. Okay, then let's start.

[00:00:23]For the past 30 years, we've built websites for humans and we focus on things like UI, performance, SEO, and accessibility.

[00:00:35]I mean, don't worry, that's not going away. But at the same time, it's no longer a full story.

[00:00:45]I don't think it's too soon to say it, so I'll just say it. Welcome to the agentic era. [laughter] This might be the biggest change for us developers since mobile or maybe even since the web itself.

[00:01:03]As more people rely on AI agents to perform heavy lifting on their behalf, the websites that are not agent ready, risking being left behind. So it's not about maintenance, it's about staying visible in this AIdriven era.

[00:01:21]I am Casper. I am a devro in Chrome AI team and today we'll talk about how to build and prepare your website for this exciting shift. We are going to answer very very important questions.

[00:01:39]How does an AI agent see your website?

[00:01:43]How to make interactions between website and agent faster and more reliable?

[00:01:48]What are WebMCP tools and how can they help us? How to audit your website for the agentic error? And last but not least, how to test and debug webmc tools.

[00:02:02]But before we get into the details, let's take two steps back.

[00:02:07]What is an agent?

[00:02:11]>> [laughter and gasps] >> So in traditional computer science, an agent is an autonomous entity that observes its environment, processes collected information and takes actions to achieve a specific goal and then continues.

[00:02:27]What has changed recently is we unlocked new capabilities. We gave agents access to a LLM, the reasoning engine.

[00:02:37]What is the agentic web then?

[00:02:42]In short, the agentic web is a web where primary users are increasingly AI agents performing complex multi-step workflows on behalf of humans.

[00:02:55]We are going from browsing to delegating. So instead of you clicking through multiple tabs to find hotel, find a car and book a flight, right? Um you can give a high level goal to an agent. The agent will do the work but human user provides the final approval on every important choice and action.

[00:03:14]That means AI agents are shifting from being simple chat bots to being active participants.

[00:03:21]They process the page structure, click buttons and trigger the actions on your behalf.

[00:03:28]There comes a new challenge. A new challenge for us developers. Building for humans is no longer enough because if an agent can't understand your site, your users lose out on automation and you miss out on conversion.

[00:03:45]So how does an AI agent actually see your website?

[00:03:52]I mean as you can imagine agent does not look at your website on a monitor, right? They use machine readable representation of your website and the quality of this representation, the machine readable representation determines their performance.

[00:04:08]An AI agent can perceive your website in three primary ways. First, it can take a screenshot and use a vision model to interpret it similarly like a human would, right? So what it sees based on screenshot, the agent recognized that the thing at the top is most likely a global search, text fields in the middle, most likely form fields, right?

[00:04:33]Visual cues can also be helpful, right?

[00:04:36]Because agent can use color, size, and proximity to determine importance. For example, big red remove button will be treated with more caution than a small help link down below.

[00:04:49]However, analyzing screenshots can be slow and expensive in terms of use tokens. So, it's it works when the structure itself is confusing.

[00:05:00]Second, the agent analyzes the DOM and read texts directly. what it sees, the nesting of elements, for example, a button instead of a div, the logical hierarchy of a dump tree, specific attributes like ids, classes that define structure, and of course, row data strings, the text, theformational backbone of your website, if you will.

[00:05:24]Reading DOM helps the agent understand the relationship between elements.

[00:05:30]If a buy now button is inside a product container, the agent knows that button belongs to that specific product.

[00:05:38]The third method, accessibility tree. So this is a browser native API that distills the DOM into what's most important, the roles, names, and states of interactive elements. It's the pages semantic summary. It's also what screen readers use. And it's very very important to mention that accessibility is for humans first.

[00:06:02]Agents just happen to benefit from it.

[00:06:06]For AI agent, the accessibility tree functions as a map that ignores all the visual noise to focus on pure utility.

[00:06:13]So by interpreting this tree, agent can understand the functional intent of every button, input, and slider.

[00:06:22]What should we do then?

[00:06:25]How can we help agents see our websites better?

[00:06:30]First big question.

[00:06:32]So, first let's talk about visuals.

[00:06:36]Make actions visible on UI.

[00:06:39]In fact, make actions extra visible on UI. [laughter] Why? Human users will have to switch their focus from any agentic surface that they are interacting with and your website. Yeah. So it also means that we should not expose functionality to it to functionality to agents that only makes background changes on the website because that would result in user having limited options to verify correct agent trajectory.

[00:07:08]Next, ensure stable layout.

[00:07:12]Think about your favorite grocery store.

[00:07:16]You know exactly where the milk is. You walk in, you pick it up, of course you pay, and then you out, right? So what happens when they decide to reorganize and put the milk back in the pharmacy section? Yeah, your cognitive load just spiked because you expected the thing to be right where you last saw it. And uh yeah, the same applies to websites. So if your buy now button is in different place for each product category, it creates unnecessary friction and can slow down agents workflow.

[00:07:50]Next, do not hide actionable controls.

[00:07:55]I want to share a term that is used in marketing in UX that I absolutely love, which is the next best action. So it's all about reducing previously mentioned cognitive load. So the next best action should not be a puzzle in welldesigned UI. It should be only logical step forward.

[00:08:20]Things that are actionable should be ideally also visible in viewport because it's it's not ideal if your buy now but buy now button requires a few scrolls down. Even even for us humans it's not ideal, right? [laughter] So if your search bar appears on hover or requires additional steps to show up or is I don't know hidden behind fancy animation, you are making it harder for both agents and humans to navigate your site.

[00:08:50]There are also certain techniques on how we can tell how we can hint agents that certain elements are actionable. For example, we can update the cursor in CSS to pointer. It gives pretty good hint to an agent. Okay, there is potentially something actionable but there are better ways of doing it. So let's talk about structural elements. If you use a semantic button or anchor elements, it's a very very strong hint to the agent that this element is actionable. The browser also make such elements focusable via tap key and makes it clickable via enter and space keys.

[00:09:29]Because if you think about it, if you want to build a fake button, you need to and you're using a div, right? You need to manually add tap index, right? Custom JavaScript to handle enter and space keys and so on as area roles and so on, right?

[00:09:44]Semantic elements like nav, header, footer. They give clear instructions on what an agent can expect to find within those regions and how to navigate the pages hierarchy with precision.

[00:09:57]Semantic HTML is the backbone of accessibility. So if your website plays nice with screen reader, if it's truly accessible, you are at least halfway there. At least halfway there when it comes to agentic readiness. If you think about it, screen readers and AI agents seek the same foundation, semantic clarity.

[00:10:22]And the beautiful irony in all of this, everything that makes a site agent ready also makes it better for humans. So [laughter] thanks.

[00:10:34]Thank you.

[00:10:36]So we do not have to create a fork of the web, a separate web to make it agent ready. If we want to build a web that AI agents can actually navigate, we do not need to reinvent the wheel. We just go, we just need to go back to the basics.

[00:10:52]Build it well, build it accessible.

[00:10:56]Some users will continue, of course, to browse the web as they have always. You know, others will use agents. And the web has always been about providing the best experience for the user no matter their device or user agent.

[00:11:12]However, [laughter] there's a catch, right? There's always a catch. However, the challenge is still there. So, it can be still challenging for agents to solve complex user intents.

[00:11:26]So, when you go to a hotel website, yeah, you also need to understand where to look for things. But you do have some mental model where to look for things because you in your life probably saw multiple websites that are similar, right? So, right upper corner, login account, right? somewhere in the middle or somewhere at the top search. Yeah. So you trigger the search and you see some search results and you might have some preferences like gym, breakfast, late checkout, right? So the journey becomes more complex and you could think of additional steps that you could potentially take. So the more complex the journey becomes, the more complex it is for the agent to synthesize all of those mentioned signals, screenshots, DOM and accessibility tree into the actionable plan. So the big question is how can we make interactions between website and agent faster and more reliable? How can we reduce mention complexities key and web MCP?

[00:12:32]>> [laughter] >> So the web MCP is a proposed web standard that aims to expose structured tools for AI agents on currently existing websites.

[00:12:49]What does it mean?

[00:12:52]It means that when a user wants to add certain kind of pizza to their shopping cart, in addition to analyzing visuals of your website, reading DOM and reading accessibility tree, agent can use tools, tools provided by your website. Because if there's a tool that can support user intent and agent can call it, the whole journey becomes more simpler because agent does not have to to synthesize every available signal. The tool is right there. [laughter] Of course, I wouldn't be myself if I didn't show you some demos, right? And um for the demos, I'll be using extension that we are using during the dev trial. Yes, the de the developer trial is still ongoing and uh this extension is something that you can use today.

[00:13:46]All right.

[00:13:55]Okay. So, we started with hotel example.

[00:13:58]So, let's continue with this. So in the right upper corner of the extension you can see webmc tools that are registered in in current context. Why do I say current context? Because tools might be available in different contexts.

[00:14:13]For example, when you have a page that is just a login page, it probably does not make sense to expose at toart tool, right? So there let's do something. Let's trigger some some some search. Let's look for for Tokyo. Let's see if the different context will have different tools. Yeah.

[00:14:32]So, filter search results, get current search results, right? So, we can register tools.

[00:14:39]Where do they make sense?

[00:14:42]Let's try something aentic. So, find me hotel in Tokyo filter for gym and breakfast.

[00:14:58]So what agent did is found tool to call search location for Tokyo then applied filters for gym and breakfast. In this extension you can see the trajectory in the in the panel down below. Right? But those are the demos that are usually shown. Yeah. Like a fine hotel, e-commerce, flight search, right? So let's let's do something that is nonobvious, right? Let's maybe try some interface where there are no user controls at all. Yeah, I like [laughter] it.

[00:15:33]Let's make a pizza.

[00:15:35]Okay, so first I want obviously I want large pizza.

[00:15:44]Okay, add cheese.

[00:15:48]Okay, add 10 bell peppers. Awesome.

[00:15:54]Add 10 mushrooms.

[00:15:58]Okay, those are not the best mushrooms to have on pizza, but [laughter] you get the idea, right?

[00:16:05]Okay, so let's try another demo that also do not provide any user controls.

[00:16:11]Let's play game maze escape. Right. So here we can trigger call the tool call manually by clicking execute tool. In this example, we have multiple tools registered to help us navigate the game like a drop, look, move, pick up and use, right? So tools are available and we can do things like move down once.

[00:16:37]Notice that I am basically talking to the website using natural language.

[00:16:41]Okay. Now move down, down and right. If I see it correctly.

[00:16:49]No, I did not see it correctly. So it cannot move to the right. Okay. So move down, right, down, left.

[00:17:05][laughter] Okay. So what what we can tell agent is for example to we can start the game once again to give the high level goal to an agent because that's that is the kind of abstraction on the complex system right so there is some complex system that provides multiple tools multiple states and we give highle goal to an agent and we let the agent do the work right of course we will not wait until the agent finishes this maze it would take us a while, but I highly encourage you to see the full demo at our WebMCP demo booth.

[00:17:46]Okay, let's switch back to slides.

[00:17:50][laughter] >> [applause] >> Okay, so we've seen great capabilities obviously right of WebMCP through the demos. But these capabilities they extend beyond the demos.

[00:18:07]Many companies have already begun testing the WebMCP through a developer trial.

[00:18:14]These organizations are evaluating WebMCP use cases, user benefits, and technical requirements. And what they find is that it significantly improves the task performance and overall user experience.

[00:18:27]Let's start with make my trip. So make my trip see WebMCP evolving to enable deeply personalized travel experiences including hotels, packages and more.

[00:18:39]Users will be able to ask nuance questions as I mentioned natural language. Yeah. Is the hotel pet friendly, kids friendly? Is it suitable for me? and so on. Policy bazar. Policy bazar experiments with WebMCP to test potential user interactions with finding relevant quotes but also to compare them. Right. Again, users will use natural language. No manual clicking.

[00:19:05]Sweet.

[00:19:07]Cyber agent experiments with their blogger blogger helper [laughter] extension. Um and they are checking if they can turn it into the agentic workflow using WebMCP. Yeah. So it seems like WebMCP will also help bloggers write personalized blogs.

[00:19:29]Okay. Before we dig into the details of what just happened, let's address the elephant in the room.

[00:19:38]How does WebMCP and MCP compare? So, WebMCP is not an extension or a replacement of MCP. Instead, WebMCP and MCP address different needs.

[00:19:51]First, the purpose. The WebMP is meant to make live website agent ready for the user right now. MCP's purpose is to make data and actions available to agents anywhere, anytime, not bound to the website. Life cycle. Web MCP is tab bound. It's ephemeral. So if tab is closed, the tools are no longer accessible.

[00:20:17]Here we are talking about currently active tab. While MCP is persistent, it runs as a server. So it's always available.

[00:20:27]Be being tabbound. Web MCP connectivity is specific to browser agents or any other kind of agent that interacts with browsers. MCP you can connect to MCP from any device anytime.

[00:20:40]UI interaction web MCP is browser integrated and DOM aware. Dumb aware in a sense that it can be the tools can be created in a way that interact with a DOM right. Um also the agent interacting with website inherits the user logged in state. So like a session cookies security context because those tools are being executed in currently active tab and uh I think it's an important bit yeah like the MCP server tools availability is not affected by the state of your website as we said it's just a server always available how does discovery happen for webmc tools are registered on the website and they are discovered during the user's visit while For MCP, you need to specifically point your agent to given MCP server.

[00:21:35]Use cases. MCP is the protocol an agent uses to talk to your backend infrastructure. WebMCP is how the same agent can interact with your front ended interface and active user session right inside the browser tab.

[00:21:51]So now you have a pretty good understanding how those two compare.

[00:21:58]Okay, let's do a quick technical deep dive. How to define WebMCP tools.

[00:22:05]You have two ways of doing this. You can do it in an imperative way using standard JavaScript or in the declarative way by adding specific attributes to HTML forms. Let's take a look at a code example of imperative API.

[00:22:22]Yeah, that's it.

[00:22:24]>> [laughter] >> So in order to register a tool you use navigator model context register tool.

[00:22:31]The tool should have name description input schema and execute block. The execute block is what will happen if your tools is called. If your tool is called parameters as a execute params they are defined in the input schema.

[00:22:49]You might ask what is add to-do item?

[00:22:52]It's your real JavaScript function that you have on your website or we have in our abstract website right now. So any JavaScript function that you can call at the end of the block you see the return statement which is basically what is being fed back to the model when the block finishes to unregister the tool. You can use a board controller and pass it as a part of the register tool down below. signal controller signal and later when the tool is no longer needed you can just do controller abort then we have a declarative API so if you already have a form it's actually very simple there are just two required parameters tool name and tool description when you provide them your form will be seen as webmc tool in the browser tool param description is optional But it gives agent needed context about how to use this input. And I think that's uh that's a very interesting thing to remember actually. So the way you name your tools, the way you provide description or description of tool parameters, this is not just a technical detail. This is being consumed by an agent. So this is very important context. How to use your tool and when to use your tool.

[00:24:14]On the right hand side [laughter] you can see how browser would translate the clarative tool into internal imperative representation and that's how you would write the same thing using the imperative way. Arguably adding few parameters to the form is way simpler.

[00:24:36]So you have tool name tool description and tool param description. Very cool.

[00:24:42]Additionally, you can add two autosubmit to your form. What it does is we say that we allow agent to submit the form after it finishes filling it up, right?

[00:24:54]And it will be automatically submitted.

[00:24:56]Uh, of course, the default behavior is that agent will just fill in the fields.

[00:25:02]It will not submit it, right? Um, there is also special attribute that you can check on an event agent invoked. So it will be true when the form was filled and invoked and submitted by the agent.

[00:25:16]Right? So what you can do here is you can basically give some additional context to the agent. Right? And uh can we quickly switch to the demo because that's what we exactly did for example from the for the f French bistro demo. If you look for the form, you can probably see the tool name, tool description, right? And then the tool is just just visible based on the form field.

[00:25:50]Back to slides, please.

[00:25:54]Okay.

[00:25:56]So you will find more details for example about event handlers and more in our developer documentation. So it was published literally this week. So you are first to hear about it. [laughter] Okay. So let's now review some good practices of building your tools.

[00:26:19]Number one, ensure clarity of scope and intended use. So we have to distinguish execution from initiation.

[00:26:28]For example, if you want to create event immediately, the tool should be called create event. But if you want to start the process of creating event, it should be called start event creation and potentially redirect to UI form.

[00:26:43]Give positive and clear descriptions. So this tool can create a calendar event scheduled for a specific date and time.

[00:26:51]The bad example, do not use this tool to check the weather.

[00:26:57]Number two, minimize cognitive compute for the model. So we have to accept raw user input and we have to anticipate what user might want to type for our tools for our website, right? So we should avoid asking the agent to perform math or transformations, right? Any calculations.

[00:27:16]So it should be all within your web MCP tool logic. If user says from 11 to 15, the tool should accept strings 11 to 15.

[00:27:27]Do not require the model to calculate minutes from midnight. Right?

[00:27:32]This can end up badly. Uh explicit types and business logic. So ensure that all parameters have specific types. Strings should be strings. Enums should be enums. Numbers should be numbers. Right?

[00:27:46]If user is ordering a product from your website, use shipping express regular instead of shipping type one, shipping type two, right?

[00:27:56]It becomes easier for agent to make a proper decision on what to put into the parameter.

[00:28:02]Turn failures into corrections. So we have to return descriptive errors. The schema constraints are helpful, but they are not guaranteed. So you should validate constraints within your function code and return proper errors.

[00:28:17]This allows the model to selfcorrect and retry with valid parameters.

[00:28:22]Good example, product name has to be a string shorter than 100 characters. Bad example parameter.

[00:28:30][laughter] How we can recover from this?

[00:28:32]Right?

[00:28:35]Graceful failure for rate limits. So tool should allow for reasonable repeated use. For example, when comparing prices or doing search, right?

[00:28:46]If rate limited, return meaningful error. So not a bad error, right? Something went wrong. Very hard to recover. And last but not least, create non-over overlapping composible tools. So tools should be atomic and composable. Each tool should have single responsibility.

[00:29:09]Avoid similar tools with nuance differences. When two tools are very similar, you can actually combine them with a s to a single tool with some input parameter that that can control them. Right? The tool registration management provide tools where they make sense. We did touch on this before. On a login page, it doesn't make sense to have a add toart tool. And um there are also certain things to consider when working with WebMCP.

[00:29:42]The browsing context is required, right?

[00:29:44]So since tools are called in and handled in JavaScript, a browsing context like browser tab or a web view must be opened, right? UI synchronization. So for a satisfactory end user experience we must ensure UI is updated to reflect the current app state regardless of whether the state updates came from human or a tool call and there is a potential complexity overhead. So in cases where the where your website UI is very complex we you most likely will need to refactor something right or add some JavaScript that handles additional states.

[00:30:23]Okay, you might say, right, that's a lot to remember, right? Screenshots, dumb, accessibility, imperative, declarative, webc, best practices, and so on. So, [sighs] how cool would it be? How cool would it be if we would have a tool that can check some of those things for us?

[00:30:43]>> Very cool.

[00:30:44]>> Very cool. Right. [laughter] Guess what we do. So starting from Chrome 150, you can run Lighthouse audit that is tailored to agentic web to check your website agentic readiness. It covers things we we discussed today like visual readiness, accessibility, audit of webmc tools, content shifts, etc. And uh it's a first call to action today. So it's still evolving and we really looking for feedback. We are looking for your help. [laughter] So please join discussions on GitHub and yeah let's build this together [laughter] [applause and cheering] and that's a beautiful segue into testing and debugging. So WebMCP is still very fresh and we have added an agent to a user journey, right? So how do we make sure that WebMCP tools we created actually work well with agents?

[00:31:47]you know.

[00:31:52]Yeah. So, we are used to testing the deterministic code, right? If A, then B.

[00:32:01][laughter] And here we are dealing with something new.

[00:32:06]AI agents that will interact with your tools are non-deterministic, right? And we'll need different techniques to make sure they work well with our tools.

[00:32:17]These techniques are called evaluations or evils for short. And while evils involve new workflows, your existing testing experience carries over directly to building great evolves.

[00:32:32]The thing is that I would need another session for evolves alone. So I really encourage you to take a look at our materials about evals and for inspiration you can check our experimental repository with evals CLI for webmc and yeah we do showcase different sets of evals for different types of use cases there okay let's now take a look at debugging so in the in testing extension in this testing extension earlier we saw details of tool available tools and [snorts] so on. But not all integrations, not all agents might offer that. So what would be what would be a great place to have all of those details?

[00:33:19]What would be the great place?

[00:33:23]Thank you. DevTools. Yes. [laughter] So yeah, so we are adding the support for WebMP in DevTools. Yeah. [laughter] So first first you see which tools are getting called during the user journey.

[00:33:40]It also means you see which tools were not called during the user journey and that can actually help you with evaluations.

[00:33:48][laughter] [gasps] Yeah. So the status of tool calls is clearly visible in the upper section of dev tools panel.

[00:33:57]You can use tool invocation counter to verify how many times tool was called.

[00:34:01]It's especially useful to verify again if certain tool was not called or called too little times or less times than you expected. Right? If there are too many tool calls in activity log, you can filter for declarative imperative status type and even search for certain strings. Exciting.

[00:34:23]For each tool, you can also review input and output. So the output here is what is returned by web MCP tool. If a tool was called by the agent, then the output is what will be returned to the agent.

[00:34:38]Last but not least, you can also find where tool is registered in sources in sources in case of imperative API and where is where is where it lives in elements in case of declarative API.

[00:34:52]Make sure to visit our demo booth so you can see it live.

[00:34:58]Yeah, there's also experimental support for WebMCP in puppeteer which can also come in very handy when you will be doing any kind of testing automation.

[00:35:11]What you can also do you can also do is you can use Chrome DevTools MCP which has experimental support for webmc to interact with your web MCP tools. Yeah.

[00:35:22]So the the tooling is already out there for you to test with the road ahead.

[00:35:34]So as discussed before, WebMCP goes beyond demos and companies are actively participating in a developer trial.

[00:35:44]And yeah, let's review some more demos here. Here we have red bus and here you can see the experimental improvements to bus booking journey. So show buses from Pune to Mumbai with AC and sleeper for a certain date. Now user wants two window seats on the highest rated bus departing in the evening.

[00:36:05]Yeah, quick and simple.

[00:36:08]Nika Nika experiments with WebMCP to create AI supported purchasing journey.

[00:36:15]Review history. Add last purchased product to the cart. Apply coupon if available. Then proceed to checkout.

[00:36:27]Easy.

[00:36:29]Gadgets now. Gadgets now is experimenting with MCP to help users find mobile specifications and apply relevant filters accurately. So the user's query 5G phone under 30,000 Indian rupees.

[00:36:46]Yeah, awesome.

[00:36:51]You can start experimenting with WebMCP today. Everything you saw today is controlled by those two Chrome flags.

[00:37:01]And what's great is origin trial which is coming soon.

[00:37:08][laughter] Yeah.

[00:37:10]>> Yeah.

[00:37:13]So, yeah, stay tuned. [laughter] And yeah, let's summarize.

[00:37:20]We began by understanding how an AI agent sees your website through a combination of screenshots, analyzing DOM, and leveraging the accessibility tree. We discussed that the agentic readiness starts with a principle we already know. Build it well. Build it accessible.

[00:37:41]We have reviewed WebMCP, the proposed web standard that aims to expose structured tools for AI agents on existing websites. I really encourage everyone to start experimenting with WebMCP and join the upcoming origin trial. And finally, we've discussed the Lighthouse audit for the agentic web.

[00:38:03]Reminder, we need your feedback and debugging your web MCP tools using the support in ChromeDev tools.

[00:38:16]Yeah, the agentic web is not a future trend.

[00:38:21]It's already here and the developers who embrace it will build websites that are ready to use for everyone, human and machine alike.

[00:38:34]Thank you.

[00:38:36][screaming]