What Is WebMCP?

Browser-Native AI Tool Registration for the Agentic Web

Last updated: March 2026

WebMCP is a browser API (navigator.modelContext) that lets websites register tools, context, and prompts directly with AI models running in the browser. Previewed in Chrome 146, WebMCP extends the Model Context Protocol from server-side to client-side, enabling any website to expose lightweight capabilities to AI assistants without requiring a separate server endpoint.

The Model Context Protocol (MCP) has rapidly become the standard way for AI models to interact with external tools. But until now, MCP has been entirely server-side: your website hosts an API endpoint, and AI agents call it remotely. WebMCP flips this model by bringing tool registration into the browser itself.

When Google's Gemini is running inside Chrome and you visit a website, WebMCP lets that website tell Gemini: "Here are the tools I offer. Here is the context about what I do. Here are the prompts that make sense for my content." The AI model can then use those tools directly — without making a separate API call to a remote MCP server.

This is significant because it removes the server-side infrastructure requirement. A static website, a WordPress blog, or a simple HTML page can register tools with browser AI assistants using nothing more than a few lines of JavaScript or HTML attributes. The barrier to entry for the agentic web just dropped dramatically.

The navigator.modelContext API

The WebMCP API lives on the navigator object — the same global that provides geolocation, service workers, and other browser capabilities. It exposes three primary methods, each corresponding to one of MCP's three primitives.

navigator.modelContext.addTool() — Register a Callable Tool

The most important method. addTool() registers a function that AI models can call. The method takes a tool definition object with a name, description, optional input schema, and a handler function that executes when the tool is called.

navigator.modelContext.addTool({
  name: "get_services",
  description: "List all services offered by this agency, including pricing",
  inputSchema: {
    type: "object",
    properties: {
      category: {
        type: "string",
        description: "Filter by category: 'development', 'ai', 'design', or 'all'",
        enum: ["development", "ai", "design", "all"]
      }
    }
  },
  handler: async (params) => {
    const services = [
      { name: "AI Agent Development", category: "ai", price: "From £5,000" },
      { name: "Web Application Development", category: "development", price: "From £3,000" },
      { name: "Agentic Web Readiness", category: "ai", price: "From £2,000" },
      { name: "Fractional AI Leadership", category: "ai", price: "£2,500-£3,000/month" }
    ];
    if (params?.category && params.category !== "all") {
      return { services: services.filter(s => s.category === params.category) };
    }
    return { services };
  }
});

Key details about tool registration:

The handler runs client-side. It executes in the page's JavaScript context. It can access the DOM, make fetch() calls to your API, or return static data. Never include secrets in the handler.
The description matters enormously. AI models use the description to decide when to call the tool. A vague description like "get stuff" will never be called. A specific description like "List all services offered by this agency, including pricing tiers and categories" gets called when the user asks about services.
The inputSchema is optional but recommended. It tells the AI model what parameters the tool accepts. Without it, the model has to guess — and it often guesses wrong.
Return structured data. Return JSON objects, not plain strings. AI models work better with structured responses they can process and present in context.

navigator.modelContext.addContext() — Provide Contextual Data

addContext() registers static contextual information that AI models can reference when generating responses about your website. This is not a callable tool — it's background knowledge.

navigator.modelContext.addContext({
  name: "company_info",
  description: "Background information about this company",
  content: {
    name: "p0stman",
    type: "Digital product studio",
    specialization: "AI applications, agentic web, voice agents",
    location: "United Kingdom",
    founded: "2024",
    website: "https://p0stman.com",
    contact: "hello@p0stman.com",
    keyServices: [
      "AI agent development",
      "Prototype to production",
      "Agentic web readiness",
      "Fractional AI leadership"
    ]
  }
});

Context is useful for information that the AI should know but doesn't need a tool call to retrieve. Company information, product descriptions, key facts — these are better as context than as tools. Use context for "who you are" and tools for "what you can do."

navigator.modelContext.addPrompt() — Register Prompt Templates

addPrompt() registers pre-built prompt templates that users can trigger. Think of these as suggested actions — "summarise this page," "find similar services," or "draft an email to this company."

navigator.modelContext.addPrompt({
  name: "draft_enquiry",
  description: "Draft an enquiry email to this agency about a project",
  template: `Draft a professional enquiry email to p0stman (hello@p0stman.com) about:
- Project type: {{projectType}}
- Budget range: {{budget}}
- Timeline: {{timeline}}

Keep it concise and mention that I found them through their website.`,
  parameters: {
    projectType: { type: "string", description: "What kind of project" },
    budget: { type: "string", description: "Budget range" },
    timeline: { type: "string", description: "Desired timeline" }
  }
});

Prompts are the least used of the three primitives so far, but they have significant potential for lead generation. A well-designed prompt template that helps users take the next step (enquire, sign up, compare options) converts AI browsing sessions into business outcomes.

Declarative vs Imperative WebMCP

WebMCP supports two approaches to tool registration. You can use either, or both on the same page.

Aspect	Imperative (JavaScript API)	Declarative (HTML Attributes)
Syntax	`navigator.modelContext.addTool()`	`data-mcp-tool="name"`
Requires JavaScript	Yes	No — browser scans DOM directly
Custom handlers	Yes — full JavaScript function	No — triggers the element's native action (form submit, link navigation)
Input schema	Full JSON Schema support	Inferred from form fields (data-mcp-param)
Complexity	More setup, more power	Minimal effort, limited flexibility
Best for	Complex tools, computed responses, API calls	Forms, navigation links, CTAs

Declarative WebMCP: HTML Attributes

The simplest way to make your website's interactive elements understandable to browser AI. Add data-mcp-tool and data-mcp-description attributes to existing HTML elements.

<!-- A contact form -->
<form
  action="/api/contact"
  method="POST"
  data-mcp-tool="submit_enquiry"
  data-mcp-description="Submit a project enquiry to discuss working together"
>
  <input
    name="name"
    data-mcp-param="name"
    data-mcp-description="Full name of the person enquiring"
  />
  <input
    name="email"
    type="email"
    data-mcp-param="email"
    data-mcp-description="Contact email address"
  />
  <textarea
    name="message"
    data-mcp-param="message"
    data-mcp-description="Description of the project or question"
  ></textarea>
  <button type="submit">Send Enquiry</button>
</form>

<!-- A navigation link -->
<a
  href="/case-studies"
  data-mcp-tool="view_case_studies"
  data-mcp-description="View portfolio of completed projects and client results"
>
  See Our Work
</a>

<!-- A pricing CTA -->
<a
  href="/services"
  data-mcp-tool="view_pricing"
  data-mcp-description="View all services with pricing information"
>
  View Pricing
</a>

Declarative WebMCP is the right starting point for most websites. It takes minutes to add, requires no JavaScript, and immediately makes your page's key actions visible to browser AI models. Add it to:

Contact and signup forms
Primary CTAs (pricing, services, portfolio pages)
Search interfaces
Key navigation elements

Chrome 146 Status and Browser Support Timeline

WebMCP was first announced by Google at I/O 2025 and shipped as an experimental feature in Chrome 146 (Canary channel, January 2026). Here is the current status and projected timeline:

Browser	Status (March 2026)	Expected General Availability
Chrome 146	Available behind flag (`chrome://flags/#model-context-protocol`)	Behind flag now
Chrome 148	Not yet released	Expected Q3 2026 — default enabled
Edge	No announcement (but Edge tracks Chrome closely)	Likely within 1-2 versions of Chrome
Firefox	Mozilla "monitoring the specification"	Unknown — possibly 2027
Safari	No announcement	Unknown

The Chrome-only status is not a reason to wait. Chrome holds roughly 65% of global browser market share. Implementing WebMCP now means you are ready when it reaches general availability — and your implementation gracefully degrades to a no-op on unsupported browsers. There is zero cost to adding it today.

To enable WebMCP for testing in Chrome 146:

Navigate to chrome://flags
Search for "Model Context Protocol"
Set the flag to "Enabled"
Restart Chrome
Verify: open DevTools console and type navigator.modelContext — it should return an object, not undefined

How WebMCP Relates to Server-Side MCP

A common misconception: WebMCP replaces server-side MCP. It does not. They are complementary technologies that serve different use cases in the agentic web architecture.

Aspect	Server-Side MCP (/api/mcp)	WebMCP (navigator.modelContext)
Where it runs	Your server (Node.js, Python, etc.)	User's browser (client-side JavaScript)
Who calls it	Remote AI agents (ChatGPT, Claude, Perplexity)	AI models in the browser (Gemini in Chrome)
Authentication	Bearer tokens, API keys	None (client-side, public tools only)
Can modify data	Yes (with auth)	Should not (security risk)
Infrastructure needed	API server, hosting, database	None — static JavaScript
Offline capability	No — requires network	Handler can return cached/static data
Best for	Complex tools, write operations, data queries	Simple reads, navigation, form discovery

The ideal setup is both. Your server-side MCP endpoint handles authenticated, complex tool calls from remote AI agents. Your WebMCP registration handles lightweight, public tool calls from browser-embedded AI models. Together, they cover both remote and local AI interaction scenarios.

Complete Implementation Examples

React / Next.js Component

For Next.js and React apps, create a client component that registers tools on mount. Import it in your root layout so it runs on every page.

// components/web-mcp-registration.tsx
"use client";

import { useEffect } from "react";

export function WebMCPRegistration() {
  useEffect(() => {
    const nav = navigator as any;
    if (!nav.modelContext?.addTool) return; // Graceful no-op

    // Tool 1: List services
    nav.modelContext.addTool({
      name: "get_services",
      description: "List all services offered by p0stman with pricing",
      handler: async () => ({
        services: [
          { name: "AI Agent Development", price: "From £5,000", description: "Custom AI agents for your business" },
          { name: "Web Application Development", price: "From £3,000", description: "Next.js, React, full-stack applications" },
          { name: "Agentic Web Readiness", price: "From £2,000", description: "Make your website AI-agent ready" },
          { name: "Fractional AI Leadership", price: "£2,500-£3,000/month", description: "Ongoing AI strategy and implementation" }
        ]
      })
    });

    // Tool 2: Search content
    nav.modelContext.addTool({
      name: "search_content",
      description: "Search p0stman's published guides and articles",
      inputSchema: {
        type: "object",
        properties: {
          query: { type: "string", description: "Search query" }
        },
        required: ["query"]
      },
      handler: async (params: { query: string }) => {
        const res = await fetch(`/api/search?q=${encodeURIComponent(params.query)}`);
        return res.json();
      }
    });

    // Tool 3: Get contact info
    nav.modelContext.addTool({
      name: "get_contact_info",
      description: "Get contact information for p0stman",
      handler: async () => ({
        email: "hello@p0stman.com",
        website: "https://p0stman.com",
        contactPage: "https://p0stman.com/contact",
        location: "United Kingdom"
      })
    });

    // Context: Company info
    nav.modelContext.addContext?.({
      name: "about_postman",
      description: "Background on p0stman digital product studio",
      content: {
        name: "p0stman",
        type: "AI-native digital product studio",
        specialization: "AI applications, voice agents, agentic web",
        founder: "Paul Gosnell",
        experience: "20+ years in digital product development"
      }
    });

  }, []);

  return null; // This component renders nothing
}

// In app/layout.tsx:
// import { WebMCPRegistration } from "@/components/web-mcp-registration";
// Add <WebMCPRegistration /> inside <body>

Plain JavaScript IIFE (For Static Sites)

For static HTML sites, WordPress, or any non-React project, use an immediately-invoked function expression (IIFE) in your shared JavaScript file.

// web-mcp.js — add to your shared scripts
(function() {
  "use strict";

  var nav = navigator;
  if (!nav.modelContext || !nav.modelContext.addTool) return;

  // Register tools
  nav.modelContext.addTool({
    name: "get_services",
    description: "List all services with pricing",
    handler: function() {
      return Promise.resolve({
        services: [
          { name: "Web Development", price: "From £3,000" },
          { name: "AI Integration", price: "From £5,000" },
          { name: "Fractional AI Leadership", price: "£2,500-£3,000/month" }
        ]
      });
    }
  });

  nav.modelContext.addTool({
    name: "navigate_to",
    description: "Navigate to a specific page on this website",
    inputSchema: {
      type: "object",
      properties: {
        page: {
          type: "string",
          description: "Page to navigate to",
          enum: ["services", "case-studies", "contact", "about", "pricing"]
        }
      },
      required: ["page"]
    },
    handler: function(params) {
      var routes = {
        services: "/services",
        "case-studies": "/case-studies",
        contact: "/contact",
        about: "/about",
        pricing: "/services"
      };
      var path = routes[params.page];
      if (path) window.location.href = path;
      return Promise.resolve({ navigated: path || "unknown page" });
    }
  });

})();

What Tools Should You Register via WebMCP?

The golden rule: lightweight, public, no-authentication tools only. WebMCP runs client-side, which means any tool handler code is visible to anyone who opens DevTools. Anything requiring a secret key, database access, or write permissions belongs in your server-side MCP endpoint.

Register via WebMCP	Keep in Server-Side MCP
get_services — list your services	create_booking — requires auth, modifies data
search_content — search published articles	get_user_data — requires auth, sensitive data
get_pricing — show public pricing	process_payment — sensitive financial operation
get_contact_info — email, phone, address	send_email — requires API key
navigate_to — help users find pages	query_database — requires DB credentials
get_faq — common questions and answers	generate_report — server-side computation

A good litmus test: if the information is already visible on your website to any visitor, it's safe for WebMCP. If it requires logging in or an API key to access, it's not.

Limit your registration to 2-3 tools on initial implementation. AI models have limited context for tool selection — too many tools degrade the quality of tool calls. Start with the tools that directly serve your most common user intent (usually: what do you offer, how much does it cost, how do I contact you).

Security Considerations

WebMCP tool handlers execute in the client-side JavaScript context. This has specific security implications:

No secrets, ever. API keys, database credentials, internal URLs — none of these belong in a WebMCP tool handler. Anyone can open DevTools and read your JavaScript.
No write operations. WebMCP tools should never modify server-side data directly. If a user needs to submit a form or create an account, the WebMCP tool should navigate them to the form or trigger the form's native action — not make a direct API call that bypasses CSRF protection.
Validate fetch() responses. If your WebMCP tool handler calls your own API (e.g., a search endpoint), validate the response before returning it to the AI model. Don't blindly pass through API responses that might contain internal data.
Rate limit API endpoints called by WebMCP. If your tool handler fetches from /api/search, that endpoint should have rate limiting. AI models may call tools rapidly in succession.
Tool sandboxing. Chrome's WebMCP implementation sandboxes tool execution — a tool handler cannot access other pages' data, localStorage, or cookies of other origins. But it can access the current page's DOM and storage.

Testing WebMCP

Testing WebMCP requires Chrome 146 with the feature flag enabled. Here's the testing workflow:

1. Verify Registration

Open DevTools console on your page and run:

// Check if WebMCP is available
console.log(navigator.modelContext); // Should be an object, not undefined

// List registered tools (API may vary — check Chrome docs)
console.log(navigator.modelContext.tools);

// Test a tool handler directly
navigator.modelContext.tools?.get_services?.handler().then(console.log);

2. Test with Gemini

If you have Gemini enabled in Chrome, visit your page and ask Gemini about your site. With WebMCP registered, Gemini should be able to answer questions using your tools rather than just the page content. Ask questions that match your tool descriptions: "What services does this company offer?" should trigger the get_services tool.

3. Automated Testing

For automated tests, mock the navigator.modelContext API:

// test/web-mcp.test.ts
describe("WebMCP Registration", () => {
  let registeredTools: any[] = [];

  beforeEach(() => {
    // Mock navigator.modelContext
    Object.defineProperty(navigator, "modelContext", {
      value: {
        addTool: (tool: any) => registeredTools.push(tool),
        addContext: jest.fn(),
        addPrompt: jest.fn(),
      },
      writable: true,
      configurable: true,
    });
    registeredTools = [];
  });

  test("registers expected tools", async () => {
    // Import and render your WebMCP component
    require("./web-mcp-registration");

    expect(registeredTools).toHaveLength(3);
    expect(registeredTools.map(t => t.name)).toEqual([
      "get_services", "search_content", "get_contact_info"
    ]);
  });

  test("get_services returns valid data", async () => {
    require("./web-mcp-registration");

    const tool = registeredTools.find(t => t.name === "get_services");
    const result = await tool.handler();

    expect(result.services).toBeDefined();
    expect(result.services.length).toBeGreaterThan(0);
    expect(result.services[0]).toHaveProperty("name");
    expect(result.services[0]).toHaveProperty("price");
  });
});

The Future of WebMCP

WebMCP is in its earliest stage. Here is where it is heading:

Cross-Browser Standardization (2026-2027)

Chrome is first, but the API is designed to be browser-agnostic. Expect a W3C working group or community group to form around the specification by late 2026. Once standardized, Firefox and Safari implementations will follow — likely in 2027. This follows the same pattern as Service Workers (Chrome first, then cross-browser within 2 years).

Richer Tool Types

The current API supports simple request-response tools. Future versions will likely support streaming tools (real-time data), subscription tools (event-driven updates), and composite tools (multi-step workflows). This will enable WebMCP to handle more complex interactions without requiring a server-side MCP endpoint.

AI-Native E-commerce

The most commercially significant application: WebMCP-enabled e-commerce. Imagine browsing a product page while asking Gemini "compare this with the alternative on the other tab." The AI calls get_product_details on both tabs and generates a comparison. Or "add this to my cart" triggering the add_to_cart tool without navigating away from the AI conversation.

Discovery Registry

Eventually, browsers may maintain a registry of WebMCP-enabled sites, similar to how they maintain a list of sites with service workers or web manifests. This would allow AI models to suggest tool-enabled websites proactively: "I found a website that can help you with that — and it has tools I can use directly."

Frequently Asked Questions

What is WebMCP?

WebMCP is a browser API (navigator.modelContext) that lets websites register tools, context, and prompts directly with AI models running in the browser. Previewed in Chrome 146, it extends the Model Context Protocol from server-side to client-side, enabling any website to expose lightweight capabilities to AI assistants without requiring a separate server endpoint.

How does WebMCP differ from server-side MCP?

Server-side MCP requires a dedicated API endpoint (/api/mcp) that AI agents call remotely. WebMCP runs in the browser — when an AI assistant is browsing your website, it can discover and use tools registered via navigator.modelContext without making additional API calls. They are complementary: server-side MCP for remote agents, WebMCP for browser-embedded AI.

Which browsers support WebMCP?

As of March 2026, WebMCP is available in Chrome 146 behind a feature flag (chrome://flags/#model-context-protocol). Google has confirmed it will be enabled by default in Chrome 148 (expected Q3 2026). Firefox and Safari have not announced WebMCP support yet, though Mozilla has expressed interest in the specification.

What is navigator.modelContext?

navigator.modelContext is the JavaScript API that implements WebMCP in the browser. It exposes three methods: addTool() to register callable tools, addContext() to provide contextual data, and addPrompt() to register prompt templates. AI models running in the browser (like Gemini in Chrome) can access these registered capabilities.

What tools should I register via WebMCP?

Register only lightweight, public, no-authentication tools via WebMCP. Good examples: get_services (list your services), search_content (search your articles), get_pricing (show pricing tiers). Never register tools that require API keys, modify data, or access sensitive information — those belong in server-side MCP with proper authentication.

What is the difference between imperative and declarative WebMCP?

Imperative WebMCP uses JavaScript to register tools programmatically via navigator.modelContext.addTool(). Declarative WebMCP uses HTML attributes (data-mcp-tool, data-mcp-description) to annotate existing page elements. Imperative is more flexible and supports complex tool handlers. Declarative is simpler and works without JavaScript — the browser scans the DOM for annotated elements.

Is WebMCP safe to use on production websites?

Yes, with caveats. WebMCP tool handlers run client-side, so never include API keys, database credentials, or internal URLs. Tools should only expose publicly available information. The API is designed to be no-op on unsupported browsers, so adding WebMCP will not break your site for users on Firefox, Safari, or older Chrome versions.

How do I test WebMCP on my website?

In Chrome 146+, enable the flag at chrome://flags/#model-context-protocol and restart the browser. Open DevTools and check the console for navigator.modelContext availability. You can inspect registered tools via navigator.modelContext.tools in the console. For automated testing, mock navigator.modelContext in your test framework.

Add WebMCP to Your Website

We implement WebMCP, server-side MCP, and the full agentic web stack for businesses that want AI models to interact with their services directly. Browser-native tool registration is the next frontier — get there first.

Agentic Web Readiness Talk to Us