Since Chrome opened its WebMCP origin trial, the question we hear most is whether it replaces the MCP server we already run at techfabric.com/mcp. We built that server so our engineers draft, check and publish posts from their own coding agent, and when we sorted its 33 tools by where each one has to run, WebMCP took a different set of jobs from the server.
The confusion is understandable, because both carry the letters MCP and both hand an AI agent a list of tools. Chrome's own engineers answered it directly in When to use WebMCP and MCP: "WebMCP is not an extension or a replacement of MCP." MCP connects agents to your services, wherever the agent runs. WebMCP connects an agent to your website while a person has it open and can watch what the agent does.
For a company deciding where to spend its next quarter of agent work, the difference decides what you build. A business with a working MCP server doesn't have to rebuild it in the browser, and a business with a busy website and no server may find WebMCP is the cheaper first step. Our own site has both halves in it, so it's the example we'll use, starting with the half that's live.
What our MCP server does for techfabric.com
The server answers at https://www.techfabric.com/mcp over Streamable HTTP, on MCP revision 2026-07-28. Anyone can connect from Claude Code, Codex, Cursor, ChatGPT or another MCP client and use nine tools with no sign-in. Those nine search and read the site, compare our case studies and run the Databricks readiness check. The other 24 tools are for our engineers. They sign in with their Microsoft Entra work account, which grants the blog.write scope, and from then on their agent can start a post, check an outline, lint a draft, file it and publish it. The server also publishes 16 prompts and 15 resources, among them the editorial rules every draft is checked against.
Three properties of that server matter for the comparison. It holds its own credentials, so a check that reads the site's private draft store runs under the server's authority, never the engineer's browser. It works with no web page open anywhere, which is why an engineer's agent can file a draft and run its checks with no browser involved. Publishing still waits for a person, because publish_draft publishes nothing on its first call and only goes ahead once the author confirms in their own client.
We wrote up how engineers use it in how our engineers turn their work into posts with coding agents, and we set the same server against Microsoft's governance tooling in Agent 365 and API Management for MCP tool governance.
What WebMCP adds to a page that's open
WebMCP is a proposed browser standard. A web page registers tools with the browser, and an agent built into the browser can call them while the visitor has the page open. Chrome's imperative API does it with document.modelContext.registerTool, giving each tool a name, a description, a JSON Schema for its input and an execute function. That function is ordinary JavaScript on the page, so it reads the same DOM, state and cookies the page already has, and the visitor is signed in as themselves.
The tools last only as long as the tab. Chrome's post calls the lifecycle "Ephemeral (tab-bound)", and once the visitor leaves the site or closes the tab, the agent can't reach those tools. Discovery works the same way, since the tools are "registered on the web page during the user's visit", with no server for anybody to add to a config file. What the visitor gets in exchange is the ability to watch. The agent fills a form or changes a filter on the page they are looking at, and they can stop it, correct it or press the final button themselves.
WebMCP is early. Chrome lists the API as an origin trial, and its docs say "WebMCP is under active discussion and subject to change in the future." The interface has already moved once. Early guides and the MCP-B polyfill use navigator.modelContext, and Chrome's page, last updated on 16 October 2026, uses document.modelContext.
Sorting our tools between the server and the page
We sorted the work by asking of each task whether it needs the visitor's open page and their own session, or has to run when nobody is looking. Everything on our server today answers the second way. Search, reading pages, drafting and the checks all work from a terminal with no browser at all, and a scheduled agent can use them with nobody at the keyboard. Publishing works from a terminal too, once the author confirms in their own client. They stay on the server.
Two tasks answer the first way, and both are on pages a buyer actually visits. The Databricks readiness check is a page with eight multiple-choice questions, and the contact form is where a conversation with us starts. Through the server, an agent can run the readiness check as assess_databricks_readiness and then hand the reader a link to the contact page. That's as far as the server can go, because the visitor's details and the moment they decide to send a message belong to the page. With WebMCP, the agent in the visitor's browser could answer the readiness questions on the page they're reading and then fill in the contact form with the topic the readout points to, while the visitor reads it over and presses Send.
The two paths start in different places. An engineer's coding agent, such as Claude Code or Codex, reaches techfabric.com/mcp over Streamable HTTP, signs in with Entra for the blog.write scope, and the tool runs on our server with no browser open. The agent built into a visitor's Chrome reaches only the tools the page registered with document.modelContext, and each one runs in the page's JavaScript, in the visitor's own session, while the visitor watches the page change.
| Task | Where it runs | Why |
|---|---|---|
| Search and read the site | MCP server | Any agent, any hour, no page open |
| Start, lint, check and file a draft | MCP server | Runs from a terminal or a scheduled agent |
| Publish a post | MCP server | Needs the server's credentials, and the author confirms in their client |
| Answer the readiness questions on screen | WebMCP, on /assessments/databricks-readiness | The visitor sees each answer as it's chosen |
| Fill in the contact form | WebMCP, on /contact | The visitor's details, and the visitor presses Send |
Take an insurer and the split follows the same question. Its claims system that an agent should query overnight is a server job. The quote form on its website, where a customer wants help but wants to see each answer before it's sent, is a page job. A business with both a platform and a public site would end up with both, which is what Chrome's post means by "Consider MCP and WebMCP as partners, not opponents."
One tool written for each side
The readiness check shows the difference in code. On the server it's registered once, for every client, and its handler runs in our Cloudflare Worker. This is trimmed from worker/mcp/interactive-tools.ts:
server.registerTool(
"assess_databricks_readiness",
{
title: "Databricks readiness check",
description: "Eight multiple-choice questions, scored into five areas, with where to start.",
inputSchema: js(INTERACTIVE_SCHEMAS.assessIn),
annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false },
},
call("assess_databricks_readiness", (args, extra) => runAssess(env, era, args, extra)),
);
On the page we'd register the same capability in the visitor's tab. Its execute function touches only the form the visitor can see, so the answers appear on screen as the agent picks them:
await document.modelContext.registerTool({
name: "answer_readiness_check",
description: "Answer the Databricks readiness questions on this page and show the readout.",
inputSchema: {
type: "object",
properties: {
answers: { type: "object", additionalProperties: { type: "string" } },
},
required: ["answers"],
},
execute: async ({ answers }) => {
fillReadinessForm(answers);
return showReadout();
},
});
The two snippets differ in where the trust sits. The server version answers anyone who connects, so it has to be safe for anyone. It's read-only, and the answers it gets are scored and never stored or logged. The page version runs with whatever the visitor's session allows, which is why we'd keep it to the readiness form and the contact form, and leave sending the message to the visitor's own click.
Where WebMCP stops today
WebMCP covers tools. Chrome's docs describe registering, listing and running them, and there is nothing in them that would carry the 16 prompts and 15 resources our server publishes, such as the editorial rules a drafting agent reads before it writes. Anything an agent needs to read as reference, outside a page visit, still needs a server.
It also reaches fewer agents. Our MCP servers page dates the client compatibility results we have for the server. Claude Code, the Codex CLI and the Gemini CLI were run for real, and Fabric Agents passed 16 of 16 checks on 22 October 2026. A WebMCP tool reaches the agent in a browser that implements the proposal. Chrome documents it, and its docs say it is subject to change. Chrome's docs also disable tool registration in cross-origin iframes by default, unless the page grants it with the tools Permissions Policy, which matters if your forms live in an embedded widget.
We'd still start on the readiness page, because a page tool is a small amount of JavaScript on a form that already exists, and if the interface changes again, the change stays on that one page. The server is where we'd keep everything that has to work for every agent, at any hour.
If you're deciding where your own agent work goes, list the tasks you want agents to do and ask of each one whether it needs a person's open page and session or has to run unattended. Connect to our MCP server to see the server half working, and talk to us if you want help exposing your own platform and site to agents.
Frequently asked questions
Does WebMCP replace MCP?
No. Chrome's own post says "WebMCP is not an extension or a replacement of MCP." MCP serves agents from a server at any time and on any platform, and WebMCP serves the agent in a browser while a visitor has your page open.
Do I still need an MCP server if my website uses WebMCP?
You need one for anything that has to work when nobody has your site open, such as background jobs, scheduled agents or agents in a terminal or desktop app. WebMCP tools exist only while the tab is open, so a site with only WebMCP is reachable only by an agent in the visitor's own browser, during their visit.
Can a WebMCP tool use the visitor's login?
Yes. The tool's execute function runs in the page's JavaScript, so it acts with the visitor's current session, the same way the page's own buttons do. On our contact page we'd let the tool fill in the fields and leave the Send button to the visitor.
Which browsers support WebMCP today?
Chrome offers WebMCP as an origin trial, and its docs say the API is under active discussion and may change. Earlier material uses navigator.modelContext, while Chrome's current docs use document.modelContext, so check the browser's own documentation before you build on it.
Can the same tool be offered through MCP and WebMCP?
Yes, and for a site like ours it often should be. Our readiness check runs on the server for any MCP client, and a page version would let the agent in a visitor's browser fill in the same questions on screen, with the server version staying the one that works everywhere.