What Is WebMCP? A Practical Guide to the Web Model Context Protocol

WebMCP is a proposed browser standard that lets websites expose structured tools directly to AI agents. Instead of forcing an agent to interpret a page visually and click through the interface like a human, WebMCP gives it a machine-readable way to discover actions and pass structured inputs. If you are new to the broader category, see A Gentle Introduction to AI Agents for the Web.

In short: WebMCP is meant to replace brittle screen-scraping with direct tool use inside the browser. As of 2026, it is still experimental and mainly available through Chrome early preview tooling.

Cheat Sheet

WebMCP Cheat Sheet

Complete quick reference to the navigator.modelContext API - registerTool, provideContext, the Declarative API, security guidance, and code examples.

View cheat sheet

Websites are primarily built for human interaction, with visual layouts, buttons, and forms designed for manual input. As AI agents become more capable of performing tasks on our behalf, they face a major challenge: they must interpret these human-centric interfaces, often leading to slow and unreliable performance. WebMCP is designed to solve this problem by creating a direct, structured communication channel between websites and AI agents.

What Is WebMCP and How Does It Work?

At a high level, WebMCP gives a live webpage a structured way to expose actions to an AI agent. Instead of forcing the agent to infer meaning from the DOM and visual layout, the page can expose machine-readable tools, inputs, and current state.

WebMCP vs. MCP vs. OpenAPI: The Fastest Way to Understand the Difference

One reason WebMCP can be confusing is that it sits next to other AI integration approaches rather than replacing them. The shortest explanation is this: WebMCP is for live, in-browser interaction with a webpage, while MCP and OpenAPI are typically used for backend or service-level integrations.

In practice, many products may eventually use more than one approach. A company might offer an MCP server or OpenAPI endpoint for backend automation while also using WebMCP to help an AI agent assist a user on the live website.

The Bridge Between Websites and AI Agents

At its core, WebMCP provides a standardized "contract" that allows a website to explicitly declare its functionality to a browser's AI agent. Instead of forcing an agent to guess the purpose of a form field or the action of a button by analyzing the page's visual structure, a website can publish a set of defined "tools" that the agent can use directly.

This approach marks a major shift away from the current common practice of screen-scraping, where an agent programmatically "looks" at a webpage to simulate human actions. That problem is closely related to the challenges discussed in How Voice Agents See and Act: A Guide to DOM Tools and DOM Downsampling for LLM-Based Web Agents.

Life Without WebMCP: The Limits of Screen-Scraping

Today, an AI agent trying to complete a task on a website operates with limited information. It must analyze the Document Object Model (DOM) and visual layout to infer meaning.

Consider an agent tasked with booking a flight. It would have to:

1. Identify input fields for "Origin" and "Destination" based on nearby text labels.
2. Locate a calendar widget and programmatically click through months and days to select dates.
3. Find a dropdown or stepper for the number of passengers.
4. Locate and trigger the "Search Flights" button.

This process is not only inefficient but also highly fragile. A small change in the website's design, like renaming a button or restructuring a form, could easily break the agent's workflow, requiring a complete reprogramming of its logic for that specific site.

The WebMCP Solution: A Contract for Interaction

WebMCP replaces this guesswork with a clear, machine-readable interface. A website can use JavaScript to register tools and their specific parameters, providing a stable API for agents. This contract defines three main areas for interaction.

It establishes a shared understanding through these key components:

• Discovery: A standard way for an agent to query a webpage and ask, "What can you do?" The site responds with a list of available tools, such as searchFlights or submitApplication.
• JSON Schemas: Each tool comes with an explicit definition of its required inputs and expected outputs. For a flight search, the schema would clearly state it needs parameters like origin, destination, and outboundDate, preventing the agent from providing incorrect or incomplete data.
• State: The protocol creates a shared context, allowing the agent to know which tools are available in real-time as the user navigates the application. For example, a checkout tool would only become available after items have been added to a shopping cart.

With WebMCP, the same flight booking task becomes a single, direct action. The website exposes a searchFlights tool. The agent can then call this tool with a structured data object, like the one below, to execute the search instantly and reliably.

{
  "origin": "LON",
  "destination": "NYC",
  "tripType": "round-trip",
  "outboundDate": "2026-06-10",
  "inboundDate": "2026-06-17",
  "passengers": 2
}

This method is faster, more resilient to UI changes, and opens the door for more complex, collaborative workflows between humans and AI agents on the web.

How WebMCP Works: The Imperative and Declarative APIs

WebMCP offers developers two distinct methods for exposing tools to AI agents. The choice between them depends on the complexity of the website's architecture and the nature of the tasks being automated. The Imperative API provides fine-grained control using JavaScript, suitable for dynamic single-page applications (SPAs). The Declarative API offers a simpler approach by adding special attributes to standard HTML forms, making it ideal for converting existing forms into agent-accessible tools with minimal code changes.

The Imperative API: Defining Tools with JavaScript

The Imperative API allows developers to programmatically manage the lifecycle of tools available to an agent. This method is highly flexible and works well in applications where the available actions change frequently based on the user's context or application state. For example, in a document editor, tools like formatText or insertImage can be registered or unregistered as the user selects different elements on the page.

Four main functions form the core of the Imperative API. They are accessed through the window.navigator.modelContext object.

registerTool

This function adds a single tool to the current set of available tools without affecting others. It is useful for incrementally adding functionality as new UI components are loaded or become active. Each tool definition includes a name, a natural language description for the agent, a JSON schema for its inputs, and an execute function that contains the logic to be run.

window.navigator.modelContext.registerTool({
  name: "addTodo",
  description: "Add a new item to the todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string" },
    },
  },
  execute: ({ text }) => {
    // Application logic to add the todo item
    return { content: [{ type: "text", text: `Added todo: ${text}` }] };
  },
});

provideContext

This function is a convenience wrapper that replaces the entire set of registered tools at once. It is suitable for major state transitions in an application, such as navigating to a completely different section of a site. It ensures that the agent only has access to the tools relevant to the current view.

window.navigator.modelContext.provideContext({
  tools: [
    {
      name: "addTodo",
      description: "Add a new item to the todo list",
      // ... schema and execute function
    },
    {
      name: "markComplete",
      description: "Mark a todo item as complete",
      // ... schema and execute function
    },
  ],
});

unregisterTool and clearContext

To manage the available tools, WebMCP provides functions for removal. unregisterTool removes a specific tool by its name, while clearContext removes all currently registered tools at once.

// Remove a single tool
window.navigator.modelContext.unregisterTool("addTodo");

// Remove all tools
window.navigator.modelContext.clearContext();

The Declarative API: Enhancing Standard HTML Forms

The Declarative API is designed to be a low-friction way to make existing websites agent-friendly. Instead of writing JavaScript, developers can annotate standard <form> elements with special HTML attributes. In current preview materials, the browser then translates these annotated forms into structured WebMCP tools that an agent can discover and use.

This approach is particularly effective for common web interactions like search forms, login pages, or data submission forms. The browser handles the creation of the JSON schema based on the form's input fields, labels, and attributes.

Key attributes for the Declarative API include:

• toolname: Defines the name of the tool (e.g., search_products).
• tooldescription: Provides a natural language description for the agent.
• toolautosubmit: An optional attribute that allows the form to be submitted automatically by the agent without requiring manual user confirmation.
• toolparamtitle: Overrides the default title for a form field in the JSON schema.
• toolparamdescription: Overrides the default description for a form field.

Here is an example of an HTML form enhanced with declarative WebMCP attributes.

<form
  toolname="my_tool"
  tooldescription="A simple declarative tool"
  toolautosubmit
  action="/submit"
>
  <label for="text">text label</label>
  <input type="text" name="text" />

  <select
    name="select"
    required
    toolparamtitle="Possible Options"
    toolparamdescription="A nice description"
  >
    <option value="Option 1">This is option 1</option>
    <option value="Option 2">This is option 2</option>
  </select>

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

In current preview examples, the browser generates a tool definition like the following from this HTML and makes it available to an AI agent.

[
  {
    "name": "my_tool",
    "description": "A simple declarative tool",
    "inputSchema": {
      "type": "object",
      "properties": {
        "text": { "type": "string", "description": "text label" },
        "select": {
          "type": "string",
          "enum": ["Option 1", "Option 2"],
          "title": "Possible Options",
          "description": "A nice description"
        }
      },
      "required": ["select"]
    }
  }
]

Handling Agent-Initiated Submissions

In current preview documentation and examples, developer control over agent-initiated actions is shown through an extended SubmitEvent flow. In that model, an agentInvoked flag indicates that the form submission came from an agent, and respondWith(Promise<any>) can be used to return a custom result instead of performing the standard form submission.

document.querySelector("form").addEventListener("submit", (e) => {
  if (e.agentInvoked) {
    e.preventDefault();
    const formData = new FormData(e.target);
    const query = formData.get("query");

    // Custom logic to handle the search
    const searchResultPromise = myCustomSearchFunction(query);

    e.respondWith(searchResultPromise);
  }
});

Current preview materials also describe visual feedback and events around agent interaction, including CSS states and page events that developers can use to react to agent-filled forms.

WebMCP Tool Design Checklist

The exact API surface may evolve while WebMCP remains experimental, but the design principles behind good browser-exposed tools are already clear. If you want an AI agent to use your website reliably, optimize for clarity, predictable state changes, and easy recovery when something goes wrong.

What good WebMCP tools should do

Three practical rules for developers

1. Separate page logic from presentation. WebMCP works best when your core business logic already exists outside click handlers and UI-only code.
2. Expose only the actions that make sense in the current page state. Tools should match what the user can actually do on the page right now.
3. Design for user-visible collaboration, not hidden automation. WebMCP is strongest when the agent helps inside a live webpage that the user can still inspect and control.

In other words, the best WebMCP implementations do not just expose functionality. They expose it in a way that is understandable to both the model and the human watching the interaction.

Practical Use Cases of WebMCP

The clearest use case for WebMCP is user-visible assistance inside a live webpage. That is also how the current Chrome early-preview materials position it: as a way for websites to expose structured browser-side capabilities to an agent without forcing the agent to reverse-engineer the interface.

A concrete example: flight search on a live webpage

The most grounded public example today is the Chrome Labs flight-search demo. A page exposes a searchFlights capability, and the agent passes structured inputs instead of clicking through form fields one by one.

searchFlights({
  origin: "LON",
  destination: "NYC",
  tripType: "round-trip",
  outboundDate: "2026-06-10",
  inboundDate: "2026-06-17",
  passengers: 2,
});

That is a good illustration of where WebMCP fits best: the user stays on the page, the UI updates visibly, and the agent works through a structured contract instead of brittle DOM guessing.

Other strong fits for WebMCP

• Design and editing tools: expose actions such as filtering templates, applying edits, or inserting structured content while the user watches the page update.
• Commerce and search experiences: expose structured product retrieval or filtering tools so an agent can narrow results without scraping listings.
• Developer and power-user apps: expose page-local actions such as log inspection, search, or suggested edits in tools that are hard to discover from the UI alone.

The key pattern across all of these is the same: WebMCP is most useful when the website already has meaningful client-side actions and wants to make them easier for an agent to call safely and predictably.

Limitations and The Road Ahead

WebMCP is a proposal for a new web standard, and as an early preview, it comes with a set of limitations and open questions that are actively being explored. Understanding these constraints is important for developers considering its adoption.

• Browsing Context is Required: WebMCP tools are executed in JavaScript within a webpage. This means a browser tab (or a webview) must be open and active for an agent to interact with the site. It does not currently support "headless" scenarios where an agent could call tools without a visible browser UI.
• Developer Responsibility for UI Synchronization: The protocol facilitates the execution of actions, but it is up to the web developer to ensure the user interface accurately reflects any state changes made by an agent. For example, if an agent adds an item to a shopping cart via a tool, the site's JavaScript must update the cart icon and item list accordingly.
• Potential for Refactoring: On websites with highly complex or tightly-coupled user interfaces, simply adding tool definitions may not be enough. Developers may need to refactor existing JavaScript to separate business logic from its presentation, making it easier to expose clean, reusable functions as tools.
• Tool Discoverability: There is no built-in, centralized mechanism for an AI agent to discover which websites support WebMCP without first navigating to them. Search engines or dedicated directories may eventually fill this gap, but for now, tool discovery is limited to the context of a visited page.

As of 2026, WebMCP should be treated as an experimental Chrome early-preview capability rather than a broadly supported browser standard. The longer-term goal is wider standardization, but cross-browser support is still part of the future roadmap.

WebMCP is not intended to replace backend integrations. Instead, it complements them by providing a solution specifically designed for the interactive, UI-driven nature of the web. A business might offer a server-side MCP API for autonomous booking while also implementing a client-side WebMCP layer to assist users who are actively browsing and refining their travel plans on the website.

Getting Started: Trying WebMCP Today

If you want to experiment with WebMCP now, approach it as an early preview workflow rather than a stable production feature. At the time of writing, testing is centered on recent Chrome 146+ builds with the relevant flag enabled, plus Chrome's debugging tooling and demo pages.

To begin, you will need two prerequisites:

• Chrome Version: Use a recent Chrome 146+ build or the current Chrome early-preview build that supports WebMCP testing.
• Feature Flag: The "WebMCP for testing" flag must be enabled.

Enabling the WebMCP Flag

First, you need to activate the feature within Chrome. This process exposes the WebMCP APIs to websites.

1. Open a new tab in Chrome and navigate to the flags page by typing chrome://flags/#enable-webmcp-testing into the address bar.
2. Locate the "WebMCP for testing" flag and change its setting from "Default" to Enabled.
3. A prompt will appear at the bottom of the screen to relaunch the browser. Click Relaunch to apply the changes.

Using the Model Context Tool Inspector Extension

To help developers debug and test their WebMCP implementations, the Chrome team has released a browser extension. The Model Context Tool Inspector lets you see which tools are registered on a page, execute them manually, and even test them with a real AI agent.

The extension offers three main capabilities for developers:

• List Registered Tools: The extension automatically detects and lists all tools registered on the active tab, whether through the Imperative API (registerTool) or the Declarative API (HTML form annotations). For each tool, it displays its name, description, and the complete JSON input schema, which is useful for debugging.
• Call Tools Manually: This feature allows you to bypass the non-deterministic nature of an AI model for initial testing. You can select a tool from the list, fill in its parameters using a JSON editor directly in the extension's UI, and execute it. The extension shows the returned result or any error messages, helping to quickly identify schema mismatches or runtime bugs in your execute function.
• Test with an Agent: The extension includes support for the Gemini API. By providing your own API key, you can enter natural language prompts and observe if the agent correctly identifies and calls the appropriate tool with the right parameters. This is a major help for optimizing tool descriptions and schemas for better model comprehension.

Hands-On with the Live Demo

The best way to see WebMCP in action is with a hosted travel demo that exposes a searchFlights tool triggerable through the inspector extension.

Manually Executing the searchFlights Tool

This exercise demonstrates how to call a tool directly with structured data, without needing an AI model.

1. With the extension installed and the flag enabled, navigate to the React Flight Search demo.
2. Click the Model Context Tool Inspector extension icon in your toolbar to open its panel. You should see the searchFlights tool listed.
3. In the panel, ensure the "Tool" dropdown is set to "searchFlights".
4. In the "Input Arguments" field, paste the following JSON object:

{
  "origin": "LON",
  "destination": "NYC",
  "tripType": "round-trip",
  "outboundDate": "2026-06-10",
  "inboundDate": "2026-06-17",
  "passengers": 2
}

5. Click the Execute Tool button. The page will update to show the flight search results.

Invoking the Tool with Natural Language

This next step simulates a real user interaction by translating a natural language request into a tool call. Note that this requires a Gemini API key.

1. Open the extension on the same demo page.
2. Click Set a Gemini API key and enter your key.
3. In the "User Prompt" field, type: Search flights from LON to NYC leaving next Monday and returning after a week for 2 passengers.
4. Click Send. The extension will send your prompt and the tool's definition to the Gemini model. The model will determine that the searchFlights tool should be called and generate the necessary JSON arguments. The extension will then execute the tool with these arguments, and the page will update with the results.

The demos and source code are open source and available for review on the Google Chrome Labs GitHub repository. If you want more context on server-side alternatives, see Top 5 Best MCP Servers for AI Agent Browser Automation. If you are comparing browser-native structured tooling with existing automation approaches, see Agent Browser vs. Puppeteer & Playwright.

Conclusion

The conventional design of the web, centered on human visual interaction, creates inherent difficulties for automated AI agents that must rely on brittle screen-scraping techniques. WebMCP addresses this gap by establishing a direct and structured communication layer between web applications and the agents that interact with them. It provides a clear contract, replacing guesswork with a defined set of tools that a website can offer.

Through its dual-API approach-a flexible Imperative API for dynamic applications and a straightforward Declarative API for standard HTML forms-WebMCP offers a path for developers to make their sites agent-accessible with a suitable level of effort. This does more than just improve the speed and reliability of automation. The protocol's design supports a future where human-in-the-loop workflows become common, allowing users to delegate complex or repetitive tasks to an AI agent while remaining in full control within a familiar web interface.

As a proposed standard in an early preview stage, WebMCP's direction will be shaped by the web development community. Experimenting with the APIs and providing feedback on use cases, API design, and tooling is an important part of maturing this technology. By giving websites a native language to express their capabilities to machines, WebMCP represents a major step toward a more programmable, accessible, and intelligent web.