The standard fix has been to build a separate integration surface for agents, usually an MCP server. That works, but it’s real infrastructure. You host it, you version it, you build OAuth for it, and you re-implement session state that your frontend already has. For a lot of web apps, that’s a meaningful cost to pay for functionality that already exists in the page’s JavaScript.

WebMCP is a proposal that removes that middle layer. The page itself registers typed tools with the browser, browser-integrated agents discover and call them, and each tool’s implementation is a function that runs code your app already has.

In the video I walk through wiring this into a production Rails app. This post is the written companion, covering what WebMCP is, the anatomy of a tool, the security boundary that does not move, and the decision framework for when WebMCP is enough and when you still want a dedicated MCP server.

What WebMCP Is (and What It Isn’t)

WebMCP is a proposed browser API that lets a web page expose tools to an AI agent built into the browser. Everything hangs off document.modelContext. A page calls registerTool with a name, a description, a JSON Schema for inputs, and an execute callback. The browser holds the registry, tags each tool with its origin, and surfaces the tools to whatever agent it hosts. When the agent calls a tool, your callback runs in the page, in the user’s existing session, and the user watches the same page update.

The spec frames it well. Pages that use WebMCP “can be thought of as Model Context Protocol servers that implement tools in client-side script instead of on the backend.”

What WebMCP isn’t deserves the same precision, because that’s where early conclusions run ahead of the spec:

• It is MCP-inspired, not MCP over the wire. Chrome’s documentation describes it as a set of “MCP-inspired” APIs rather than a JavaScript implementation of MCP. It has tools only, with no resources, no prompts, no JSON-RPC, and no transport. The browser mediates everything.
• It is a Draft Community Group Report, not a W3C Standard. It was proposed by Microsoft and Google engineers in August 2025 under the W3C Web Machine Learning Community Group, and the current draft was last revised August 26, 2026. It is not on the W3C Standards Track. That can change, but today you are building against a moving proposal.
• It is not a discovery mechanism. Tools exist only while a user has your page open. There is no crawlable manifest. WebMCP does not replace structured data, readable content, or a public API.
• It is not headless automation. The design intent, in Chrome’s words, is local browser workflows with human oversight. A cron job cannot call your WebMCP tools. Neither can Claude Code.

Who consumes these tools matters more than the spec text. As of August 25, 2026, OpenAI ships WebMCP support (branded “Site tools”) in the ChatGPT desktop app’s built-in browser, Codex, and ChatGPT Sites. Google has said Gemini in Chrome will consume WebMCP tools, though I haven’t seen that confirmed as shipping. Before the OpenAI launch there was no mainstream consumer at all, which tells you how early this is.

A Tool Is Four Things

Every WebMCP tool is the same four parts:

1. A name. The identifier the agent calls. Keep it short, stable, and unambiguous.
2. A description. Natural language explaining what the tool does and when to use it. This is what the model reads to decide whether the tool fits the task, so write it the way you’d write for a new teammate, including side effects.
3. An input schema. JSON Schema describing the parameters. This is the contract that replaces guessing at your form fields.
4. An execute function. A callback that does the work. It’s a thin wrapper around code your app already has, calling the same functions your own UI calls, not new logic you write for the agent.

Here’s the shape, trimmed from the pattern I use in the video. The app validates video ideas, and this tool submits one:

// app/javascript/webmcp/tools.js
if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "submit_video_idea",
    description:
      "Submit a video idea for validation. Starts an async research job. Returns the idea id to use when polling for the verdict.",
    inputSchema: {
      type: "object",
      properties: {
        title: {
          type: "string",
          description: "Working title for the video idea",
        },
      },
      required: ["title"],
      additionalProperties: false,
    },
    async execute({ title }) {
      // The same code path the submit button already uses
      const idea = await submitIdea({ title });
      return {
        content: [
          { type: "text", text: `Idea ${idea.id} submitted. Validation is running.` },
        ],
      };
    },
  });
}

Four details in this example matter:

• Feature detection is mandatory. Most browsers don’t have document.modelContext yet, so the guard clause keeps the page working everywhere else. This mirrors the pattern OpenAI recommends in their WebMCP guide.
• The return value goes back to the model. Return enough for the agent to verify the result and take its next step, like the id it needs for polling. The browser stringifies the result for the model.
• Annotations tune trust. Mark non-mutating tools with annotations: { readOnlyHint: true } so the browser can skip confirmation prompts, and mark tools that return user-generated or external content with untrustedContentHint.
• Registration is scoped. You can pass an AbortSignal to unregister a tool when app state changes, and provideContext replaces the whole toolset at once. Tools should reflect what the current page can actually do.

There’s also a declarative variant where you annotate an ordinary form with toolname and tooldescription attributes and the browser derives the tool schema from the fields. It’s a nice fit for lead capture and booking forms, but ChatGPT’s browser only supports the imperative API today, so I’d treat the declarative form as something to watch rather than ship.

If most of your product’s behavior already lives in client-side functions, that’s the whole integration. The work is choosing which capabilities to expose and writing honest descriptions.

Removing the Middleware Doesn’t Remove the Security Boundary

Because there’s no separate service to stand up, it’s easy to assume there’s no new security work either.

A WebMCP tool runs in the page with the user’s session and cookies. The agent’s cart is the user’s cart. That’s the feature, and it’s also the risk: every tool you register is a new entry point into your application, operated by a model that reads untrusted content all day. The spec’s own security section describes prompt injection through tool descriptions and tool outputs, over-privileged tools, and schemas that invite the model to pass sensitive data.

The working rule is that nothing about your backend security model changes. Authentication, ownership checks, quotas, and rate limits stay server-side, exactly where they were before WebMCP existed:

• Auth stays on the server. The tool rides the existing session. Your server still decides what that session is allowed to do.
• Ownership checks stay on the server. A list_channels tool returns the current user’s channels because the endpoint scopes the query, not because the tool’s description promises to behave.
• Quotas and validation stay on the server. If submissions are limited per plan, the limit is enforced where it always was. execute can validate inputs for fast feedback, but client-side validation remains a UX courtesy, not a control.

If a capability would be unsafe as a public endpoint called by a hostile client, it’s unsafe as a WebMCP tool. The browser adds real mitigations on top (confirmation prompts for sensitive actions, origin isolation, a Permissions Policy for tools, and ChatGPT treats all site-provided tool definitions as untrusted), but those protect the user from your tools. Protecting your system from a confused or manipulated agent is still your job, and it lives behind the same boundary it always did.

WebMCP removes the integration layer, not the trust boundary. Expose the narrowest capability that serves the task, and let the server keep saying no.

WebMCP vs MCP: When Each One Fits

WebMCP does not replace a dedicated MCP server, and both Chrome and OpenAI say so directly. Chrome’s guidance is to treat them as “partners, not opponents.” OpenAI’s split is that MCP fits searching a service or managing records through an API, while WebMCP fits the moments when “you and the agent need to see the same thing.”

The structural differences drive the decision:

When I’m deciding for a specific capability, I ask these questions in order:

1. Is there a browser session with your page open while the task runs? This is the hard constraint, and it’s about the tab, not the human. Tools exist only while a WebMCP-capable browser has your page loaded, so a cron job, a backend service, or a CLI agent like Claude Code has no path to them. Those clients need an MCP server or a plain API.
2. Is the work attended or unattended? Nothing in the API strictly requires a human watching, and an agent driving its own browser can call your tools without one. But the stated design intent is human oversight, the browser leans on user confirmation for sensitive actions, and today’s consumers are built around an attended session. I’d treat WebMCP as the attended path and put unattended automation on MCP, where auth and rate limits are designed for exactly that.
3. Does the action need the page’s live state or session? A cart, an unsaved draft, a filtered dashboard. This is where WebMCP is the natural fit, because a separate server would have to replicate that state to act on it.
4. Does the logic already exist client-side? If yes, WebMCP costs almost nothing. If the logic only exists behind an authenticated server API, an MCP server may be nearly as cheap to build and reaches far more clients.
5. Is the answer “both”? Then share the implementation. Keep the business logic in one place, expose it through MCP for headless clients, and register thin WebMCP tools in the page that call the same functions for in-browser collaboration.

The failure mode to avoid is treating this as a versus decision at the company level. It’s a per-capability decision. Checkout with a live cart wants WebMCP, nightly reporting wants MCP, and both can sit on the same service layer.

What This Looks Like in a Production App

In the video I wire WebMCP into CreatorSignal, a production Rails app of mine that validates YouTube video ideas and returns a scored Go, Refine, or Kill verdict. It’s the same app from my Linear agent loop post. The demo exposes three tools, and the trio is deliberate because each one teaches a different part of the pattern:

• List channels is the read-only tool. This is where readOnlyHint belongs, and where the server scopes the query to the signed-in user. It exists so the agent can ground itself in real data instead of guessing at ids.
• Submit a video idea is the write tool. It belongs on the same code path the form submit uses, so every server-side check that protects the form protects the tool for free.
• Poll validation status exists because the interesting work is async. Validation runs as a background job, so the submit tool returns an id and this tool reports the job’s progress until the verdict lands. Tab-bound tools can’t wait around for a slow job, so you give the agent a way to check back, the same way you’d design a polling endpoint for any client.

The polling tool is the one that generalizes. Most real applications have async work in them, and “return an id, poll for status” translates directly from API design into tool design. Good WebMCP tools end up looking like good API endpoints with better documentation. The disciplines are the same ones as MCP tool design: narrow inputs, described side effects, and enough in the return value for the caller to verify what happened.

Where WebMCP Stands Today

WebMCP is early, and the specifics of how early should shape how much you build on it.

On August 5, 2026, Shopify enabled WebMCP tools on every Liquid storefront and the Hydrogen developer preview, with nothing for merchants to install. Ten tools covering catalog search, cart, checkout, and store policies. That’s precise scope, every Liquid storefront rather than every Shopify store, but it’s still one platform making a large slice of commerce agent-usable by default. Combined with OpenAI shipping a consumer, the chicken-and-egg problem that stalls most web proposals has a crack in it.

Now the caveats I’d weigh before committing:

• The API is still moving. In July 2026 the spec relocated the API from navigator.modelContext to document.modelContext, and Chrome 150 deprecates the old path. Early adopters are already carrying migration debt, and I would expect more of it before this stabilizes.
• The consumer base is narrow. Chromium only, and actual consumption today is effectively the ChatGPT desktop browser. Whether Gemini in Chrome ships, and whether Anthropic’s browser agent consumes WebMCP tools, are open questions.
• There is no discovery story. Tools are invisible until a user lands on your page. WebMCP is a better contract for agents that already arrive, not a way to attract them.

None of that makes it a bad bet. The integration cost is low precisely because the tools wrap code you already have, which caps the downside. But go in knowing you’re adopting an origin-trial API, not a settled platform feature.

How I’d Start

If you own a web app and want to try this, the path I’d take is small and low-commitment:

1. Enable the flag in Chrome 149+ (or register for the origin trial for real users) and install Chrome’s Model Context Tool Inspector extension so you can see and execute registered tools manually.
2. Register one read-only tool that wraps a function your app already has, with readOnlyHint set and a description you’d be comfortable showing a new hire.
3. Add one write tool that goes through the exact code path your UI uses, and confirm your server-side auth, ownership, and quota checks fire when the tool calls it.
4. Only then decide whether a dedicated MCP server belongs in the picture, using the questions above per capability rather than picking a side.

That ordering keeps the security boundary honest and gives you a working demo in an afternoon instead of an infrastructure project.

If you’re working out how your product should meet AI agents, whether that’s WebMCP tools, an MCP server, or the service layer that backs both, this is the kind of architecture decision I help teams make. See how I help teams build agentic systems.

Further Reading

• WebMCP specification is the Draft Community Group Report itself.
• WebMCP explainer and repo covers the motivation, the declarative API, and open questions.
• Chrome’s WebMCP documentation includes the imperative and declarative API guides and tool security guidance.
• Comparing WebMCP and MCP is Chrome’s own take on the decision this post frames.
• OpenAI’s WebMCP guide for ChatGPT documents what Site tools support today.
• Shopify’s WebMCP changelog entry details the default-on storefront tools.
• WebMCP: How to Make Your Site Agent-Ready Without the Middleware (YouTube) is the companion video where I wire these tools into a production Rails app.