What is WebMCP? The guide from a site that runs it

WebMCP involves three parties. The page declares tools. The browser keeps the list and carries calls back and forth. The agent, built into the browser, running as an extension or inside a desktop app’s browser, reads the list and decides what to call. There is no server in the middle: as an engineer put it at BlinkOn 21, the browser plays the part an MCP server would play, but no actual server is involved.

1. The page

   Registers tools from its own JavaScript and runs them when called: the same functions as its buttons, the same cookies, the same permissions.

2. The browser

   Holds each tab’s tools, hands them to the agent, routes calls into the page and keeps the human in view.

3. The agent

   Reads names, descriptions and schemas, picks a tool, sends arguments, and reads the string that comes back.

• It runs as the user

  Tools execute inside the open tab, with the session the person already has. No API key, no OAuth flow, no new credential: when the tab closes, the access ends with it.

• It lives and dies with the page

  Tools exist only while the page that registered them is open. Navigate away and they’re gone; the next page registers its own. Chrome’s Kasper Kulikowski calls it tab-bound and ephemeral.

• It keeps the human in the loop

  The design target is co-browsing: the person watches the page change as the agent works and keeps the consequential steps. A form tool fills the fields; by default, the human presses submit.

• It shows only what the user may do

  Tools are registered by the page’s code, for the person in front of it. A logged-out visitor’s agent never sees “checkout”, because the page never registers it.

• It degrades gracefully

  No tool for the job? The agent falls back to the interface, as before. WebMCP is a faster, safer path for agents, not a gate.

There are two flavours. The imperative API is JavaScript and can do anything. The declarative API is a handful of HTML attributes on a form you already have. To the agent there is no difference: in the words of specification editor Dominic Farolino at BlinkOn, there are really just tools.

if ("modelContext" in document) {
  const registration = new AbortController();

  await document.modelContext.registerTool(
    {
      name: "search_flights",
      description:
        "Search flights between two airports on one date. " +
        "Returns up to 10 offers with price, duration and stops.",
      inputSchema: {
        type: "object",
        properties: {
          from: { type: "string", description: "Departure airport, IATA code" },
          to: { type: "string", description: "Arrival airport, IATA code" },
          date: { type: "string", format: "date" },
        },
        required: ["from", "to", "date"],
      },
      annotations: { readOnlyHint: true },
      async execute({ from, to, date }, { signal }) {
        // The same function the search button calls.
        const offers = await searchFlights({ from, to, date, signal });
        // The person sees what the agent asked for.
        showResults(offers);
        return offers.slice(0, 10);
      },
    },
    { signal: registration.signal },
  );
}

// Later: registration.abort() removes the tool.

<form
  toolname="book_table"
  tooldescription="Book a table for a date, a time and a party size."
  action="/reservations"
  method="post"
>
  <input name="date" type="date" required>
  <select name="time" required>
    <option>19:00</option>
    <option>20:30</option>
  </select>
  <input name="guests" type="number" min="1" max="12" required
    toolparamdescription="Number of people, 1 to 12">
  <button>Book</button>
</form>

Many teams will run both. Shopify ships Checkout MCP for agents on servers and Checkout WebMCP for agents in the buyer’s browser, over the same checkout object, and tells developers to use the server version whenever the agent can run on a server. MCP Apps go the other way round from WebMCP: they bring a site’s interface into the agent’s chat, while WebMCP brings the agent into the site.

1. Mar 2025

   The name appears

   Developer Jason McGhee publishes a project called WebMCP, the first use of the name, to let websites offer tools to local AI clients.

2. Jun–Jul 2025

   An MCP server inside a web page

   At Amazon, Alex Nahas wanted colleagues to use agents on internal tools. Remote MCP relied on OAuth, Amazon ran on SAML single sign-on, and the internal MCP server had grown to thousands of tools. His answer: run the server in the JavaScript of a page the user is already logged into. He calls it MCP-B (the B stands for browser, because “Browser MCP” was taken), and his Show HN lands on July 9.

3. Jul 2025

   Two browser teams, the same idea

   On July 9, Chrome files an intent to prototype a “Script Tools API”. On July 16, Microsoft Edge publishes its “Web Model Context” explainer, written by Andrew Nolan and Brandon Walderman.

4. Aug 2025

   One proposal

   The two proposals merge in the W3C Web Machine Learning Community Group between August 7 and 18, with Nahas’s work credited as implementation experience. On August 29, Patrick Brosset shows an Edge prototype driven from VS Code.

5. Sep 25, 2025

   Formally on the W3C table

   The group’s revised charter takes effect with WebMCP as a deliverable. Editors: Khushal Sagar and Dominic Farolino (Google), Brandon Walderman (Microsoft). In November, the group meets at TPAC in Kobe and Sagar presents WebMCP at Google’s Web AI Summit.

6. Feb 10, 2026

   Chrome’s developer trial

   Chrome 146 ships WebMCP behind a flag, with an inspector extension to call tools by hand. Chrome’s developer relations team admits it hasn’t yet tested with real agents.

7. Mar–Jun 2026

   The API is rebuilt

   provideContext and unregisterTool go, modelContext moves to document, the consent hook is removed for now. On June 11, Apple’s WebKit team formally opposes the proposal.

8. May–Jun 2026

   From I/O to the origin trial

   At Google I/O on May 19, Chrome announces an origin trial, a WebMCP panel in DevTools and an agentic browsing category in Lighthouse. The trial opens on June 9, from Chrome 149 to 156.

9. Aug 2026

   Sites and agents arrive

   Shopify storefronts register tools from August 5, the day Mozilla sets its position to neutral. On August 25, ChatGPT’s desktop browser starts calling them. Google’s WebMCP Challenge draws about 5,000 entries.

10. Sep 2026

    Headless in scope, ship date open

    consequentialHint lands and headless agents come into scope. Shopify’s checkout follows on September 28. On September 29, Chrome asks to extend its trial to version 162 and hopes to ship within that window. On October 1, the charter of a new Agentic Web Working Group enters review.

WebMCP is a Community Group draft, not a W3C standard. A standard needs more than one engine, and today only Chromium implements it. Inside the W3C, the accessibility and privacy groups are critical too.

• Implementing

  Google Chrome

  Two of the three editors. Developer trial from Chrome 146, origin trial from 149 to 156, extension to 162 requested, no intent to ship yet.

• Implementing

  Microsoft Edge

  One editor and the first prototype. Edge runs the origin trial too.

• Calling tools

  OpenAI

  ChatGPT’s desktop browser calls WebMCP tools since August 25, 2026: JavaScript tools on the top-level page only.

• Neutral

  Mozilla Firefox

  A prototype behind a setting that is off by default. Interest in the JavaScript API, objections to a name that promises MCP.

• Opposed

  Apple Safari

  Wants the gaps fixed in HTML and ARIA, and has said it would formally object if WebMCP moved to a Working Group as is.

• Not as it stands

  W3C accessibility group

  Says it does not support the spec in its current form, and calls toolautosubmit a vector for deceptive patterns similar to clickjacking.

WebMCP makes an agent’s work explicit, which narrows what it needs to touch. It doesn’t make agents safe. The specification says so itself: there is no guarantee that a tool’s declared intent matches its actual behaviour.

1. 01

   Words become attack surface

   Names, descriptions and results all land in the model’s context. A malicious page can hide instructions there, and an honest page can relay them by returning reviews or forum posts. Mark such results with untrustedContentHint and say it in words too, as OpenAI’s documentation site does.

2. 02

   The first script to register wins

   Tool names are unique per page, so a compromised analytics or ad script that registers checkout first owns it. In a 2026 lab study (arXiv 2606.06387), that race hijacked GPT-5.4, Claude Opus 4.6 and Gemini 2.5 Flash in every trial.

3. 03

   Capabilities laundered into English

   Earlence Fernandes (UC San Diego) planted a dormant instruction in one site’s tool description; later, on another site, a trigger word made the agent call that site’s tool. Origin isolation is only as strong as the agent’s defence against prompt injection.

4. 04

   Your Approve button is not a safeguard

   Tools act with the user’s cookies, and an agent that can call tools can usually click too. On September 2, 2026, a developer reported ChatGPT’s browser calling a proposal-only tool, then pressing the page’s own Approve button; the page logged “approved by you” (issue #288). Shopify’s rule: the agent shows the order and total, asks the buyer, and asks again if the total changes.

5. 05

   Tools vanish mid-flight

   Results die with the document. If a call makes the page navigate, the answer may never arrive (Shopify notes that executeTool() then returns null), and agents sometimes fail to find re-registered tools after the trip.

6. 06

   Nobody can see agent traffic yet

   Sites can count calls, not whether those calls served what the user wanted. Shopify’s Yoav Weiss opened an issue for real-user measurement; an early commerce deployment reports it cannot yet observe real agent traffic.

1. Think in tasks, not elements

   One tool per job a user comes to do, not one per button. Name what it does: create_event executes, start_event_creation opens the form.

2. Keep the list short

   Dozens of tools degrade agents and can make browsers drop some. Register on each page only what that page can do.

3. Respect the budgets

   Chrome’s limits: 30 characters per name, 500 per description, 150 per parameter description, about 1,500 per result. Put the critical caveat first: overflows are cut silently.

4. Accept raw input

   Take “11 to 15” the way the user said it; don’t ask the model for minutes since midnight. Use readable enum values: “express”, not 1.

5. Validate in code, loosely in schema

   Schema constraints aren’t guaranteed to be enforced. Check inside execute and return errors that say how to fix the call.

6. Show what happened

   Update the visible interface on every call: the person shares the tab with the agent.

7. Label what you don’t control

   untrustedContentHint on results with user-generated content, and the same warning in the description.

8. Leave the decision to the human

   consequentialHint for payments, sends and deletions, a confirmation step in the flow, and prices and stock checked again at execution.

9. Survive navigation

   Do the work in the page and return data, make navigation its own tool, and register the same names on every page.

10. Detect, load late, clean up

    Check document.modelContext (older Chrome: navigator.modelContext), load tool code only then, and pass an AbortSignal.

11. Mind your third-party scripts

    Register critical tools early, and audit the tags that share your page.

12. Test like an agent

    Chrome’s Model Context Tool Inspector, the DevTools WebMCP panel, Lighthouse’s agentic browsing audit, and a browser test that calls the real tools.