From Browsing to Asking: The Web Learns to Take Action

A couple of months ago, I wrote an article titled AI Agents Will Deeply Transform Our Experience With the Web. I shared my vision of how AI agents will radically change our experience with the web. I concluded by saying that a new paradigm would emerge: "Website as a Search Bar." I never really explained what I meant because it was more of a feeling, based on my reading of the ecosystem, than something concrete.

Since then, a lot has changed, and that idea is now a reality. I never expected the future to arrive so quickly. Things have been moving insanely fast lately.

In that future, which is already here, we will ask agents to take action, and I already love it.

Website as a Search Bar ​

Today, we navigate the web. We click links, scroll through pages, fill out forms, and read content. The same used to be true of my work as a software engineer. Since I started using AI agents, that is no longer the case for me. Now, I ask them to take action more often than I perform those actions myself. That new behavior is coming to the web.

The idea behind "Website as a Search Bar" is that a website's main page will simply be a search bar: an input where we can ask for anything we want to do on the website. Behind the scenes, the website will have an agent that acts for us. When I first thought about it, I imagined an MCP server and a server-side agent. The agent would call the MCP server to perform actions, and the UI would intelligently adapt or refresh based on the server's response. That experience is similar to what Notion AI offers today, and it works very well.

However, a new approach has recently begun to emerge.

The Chrome team is developing two new APIs that could completely reshape how a website becomes a search bar:

1. WebMCP, which lets you build and expose structured tools for AI agents;
2. The Prompt API, which lets you send natural language requests to an LLM in Chrome.

With both, we can now have client-side agents that perform actions on the web on our behalf. This is mind-blowing.

The future is already here ​

Yes, that sounds crazy, I know, but the future is already here.

Both WebMCP and the Prompt API are already available experimentally in Chrome. This is no longer just a discussion, an idea, or a specification: experimental implementations are available and working. You can now create a website that exposes WebMCP tools, and you can chat with an in-browser AI. Cloudflare is also experimenting with WebMCP through its BrowserRun product, and ChatGPT Desktop supports WebMCP to make browsing the web easier for agents.

In-browser AI refers to LLMs such as Chrome's Gemini Nano or Google's Gemma models that can run privately and entirely in the browser on your computer. I'm not talking about Codex or Claude connecting to your browser and performing actions by reading the DOM or taking screenshots. I'm talking about an agent whose model can run offline and use dedicated APIs to interact seamlessly with websites.

Ask for actions ​

To make the idea more concrete, I built a small demo showing how it works. At first, my goal was simply to explore and use WebMCP. It turned into something bigger than I expected because, apart from a test browser extension, I couldn't find any other tool for testing it.

What did you just see?

We are using code, my tool for turning raw code into beautiful, shareable images. You paste a code snippet, select the language and background color, and capture it as an image. Then, you can share it with anyone on social media.

Normally, the user performs all the actions I've described manually.

The agent edits the code using the prompt provided, changes the settings, and finally takes a screenshot of the result. In the end, that is nothing more than what a human can do, but a local agent performs all those actions. That is the real change, and that is the future.

I know that this demo is useless. However, it gives you a concrete idea of this new paradigm. Everything, from the interface to the experience, still has to be invented and designed.

Two APIs to make it happen ​

If this is the future, we should take a closer look at the two APIs that make it possible. I have good news for you: on the surface, they are dead simple. However, the new doors they open make using them more complex than they initially seem.

WebMCP comes in two forms:

1. An imperative API for defining tools using JavaScript;
2. A declarative API for defining tools using HTML annotations.

The first is similar to the way an MCP server defines tools.

await document.modelContext.registerTool({
  name: 'performAction',
  description: 'Perform an action on the page.',
  inputSchema: {
    type: 'object',
    properties: {
      input: { type: 'string' },
    },
    required: ['input'],
  },
  execute: async ({ input }) => {
    // Add the logic to perform the action here
  },
})

The document gets a new property called modelContext, which is the entry point for creating and registering tools on the current page. Agents using your site need to know which tools are available, so modelContext exposes a getTools() method that returns the list of tools available on the page.

const tools = await document.modelContext.getTools()

This is similar to the listTools() method exposed by createMCPClient() in the AI SDK. It can be a little confusing because, in the browser, we act as both the server by registering tools and the client by accessing them. That is because your website is not necessarily the consumer of those tools.

You can also execute a tool using the executeTool() method of the modelContext object.

const [tool] = await document.modelContext.getTools()

await document.modelContext.executeTool(tool, JSON.stringify({
  input: '...',
}))

The second is the declarative API, which lets you define tools using HTML annotations. It is primarily designed for forms:

<form toolname="supportRequestTool"
  tooldescription="Submit a request for support."
  action="/submit">

  <label for="firstName">First Name</label>
  <input type=text name=firstName>

  <label for="lastName">Last Name</label>
  <input type=text name=lastName>

  <select name="select" required
    toolparamdescription="Determines what team this request is routed to.">
    <option value="Customer happiness team">Return my purchase.</option>
    <option value="Distribution team">Check where my package is.</option>
    <option value="Website support team">Get help on the website.</option>
  </select>

  <button type=submit>Submit</button>
</form>

Then comes the Prompt API. It is more complicated because it requires more availability and lifecycle management. For example, you need to detect whether the in-browser LLM is available. If it isn't, you need to know why. Maybe the device is incompatible, or the LLM hasn't been downloaded yet. If it can be downloaded, you have to tell the browser to download it, which can take a while. You therefore need to inform the user that something is happening in the background. On top of that, the API exposes low-level primitives that you probably don't want to deal with directly.

That is more work than calling an API. The good news is that a community provider called Browser AI makes the Prompt API easier to use with the AI SDK.

import { browserAI } from '@browser-ai/core'
import { streamText } from 'ai'

const model = browserAI()

const { textStream } = streamText({
  model,
  prompt: 'Describe the future of the web in five sentences.',
})

for await (const textPart of textStream) {
  console.log(textPart)
}

That's only the beginning ​

For now, even though you can already test both APIs, they remain experimental and have limited browser support. This means that most people won't be able to use them. They still need to be standardized and adopted by other browser vendors, such as Mozilla and Apple.

Also, in-browser models are limited, especially compared with state-of-the-art models. They can answer questions and call tools, but you have to keep both the instructions and tool parameters simple, really simple.

They will inevitably become smarter and smarter. Recently, Qwen released Qwen3.8-27B, a model that can run on some consumer devices. Google is also making significant progress with its Gemma series of models, which are designed to run on-device. Devices are becoming more powerful and better able to run these models. Apple's M-series SoCs include a Neural Engine, or NPU, and Google has done the same with its Tensor SoCs. The latest version of Siri also performs AI work on-device, and it seems really powerful. Now, it is only a matter of time.

Finally, when all of this is standardized and mature, having everything ready to use will give you a competitive advantage.

While I was writing this article, OpenAI announced a WebMCP challenge to explore what is possible. It looks like I'm heading in the right direction.