Download PDF (576 KB)
PDF version, ready to print or share with your team.
Somewhere in the last few months, “make your website agent-ready” became a sales line. It arrives in vendor decks and cold emails aimed at Canadian business owners, usually attached to a warning about falling behind. The technology underneath the pitch is real and it has a name.
What the pitch leaves out is what the standard actually does, what it does not do, and the class of attack that security researchers published against it in June 2026.
Fusion Computing deployed WebMCP on its own website on 2026-08-26, with a public MCP server beside it that we later took down. The findings below are first-hand, and several of them contradict the tutorials. The security review behind them was run by Mike Pearlstein, CISSP, who has led the firm since 2012.
What is WebMCP?
WebMCP is a proposed browser standard that lets a website hand structured, callable tools to an AI agent running in the visitor’s browser. The page declares each tool with a name, a description and a JSON Schema, and the agent invokes it directly rather than guessing at the page layout. The specification is a draft report from the W3C Web Machine Learning Community Group (2026).
An origin trial is a time-limited browser experiment: a site opts in with a token, and the feature switches off when the trial ends unless the browser ships it.
The mechanism is a single browser API. A page calls document.modelContext.registerTool() and passes a tool definition. An agent in that browser can then list the available tools and call them with structured arguments, receiving structured results back.
Google’s WebMCP documentation calls the API “under active discussion and subject to change”, so older tutorials may show calls that no longer work.
How is WebMCP different from an API or an MCP server?
A REST API serves developers, a remote MCP server serves an assistant running anywhere, and WebMCP serves an agent inside the visitor’s own browser session. That session distinction carries the value, because the agent already holds the user’s login, cart and context. The W3C explainer (2026) lists headless browsing as an explicit non-goal of the design.
| REST API | Remote MCP server | WebMCP | |
|---|---|---|---|
| Who calls it | A developer’s code | An AI assistant, anywhere | An agent in the visitor’s browser |
| Whose session | User or service credentials | The connector’s credentials | The visitor’s own login |
| Needs an origin trial | No | No | Yes, Chrome 149 to 156 |
| Do AI crawlers see it | No | No | No |
The three do different jobs. On our site one set of tool definitions sits behind both WebMCP and the ordinary calculator pages, so a calculator gives an agent the same answer it gives a person.
What actually changes for a business website
WebMCP makes a site operable by browser agents and leaves how it is found unchanged. Google’s Chrome documentation (2026) scopes the API to agents running inside a real browser session, and search crawlers such as OAI-SearchBot and PerplexityBot index fetched HTML rather than a live browser session. A site that adds WebMCP becomes usable by agentic browsers and no more visible in search results.
That distinction is the one most likely to be blurred in a sales conversation.
Want a plain answer on whether agent-readiness is worth it for your site →
An owner running a WebMCP-aware browser agent or extension can ask their browser to price a service, run a readiness assessment or start a contact request. The site answers with real structured output rather than the agent scraping a form it half understands.
Google has highlighted Expedia, Booking.com, Shopify, Redfin, Etsy, Instacart and Target as brands experimenting with WebMCP. That is a reasonable signal of where large consumer brands expect the behaviour to matter first.
What we found shipping it: four things that are not in the documentation
Four defects surfaced during the fusioncomputing.ca deployment on 2026-08-26 that we did not find in the documentation and tutorials we reviewed. The most damaging involves spam honeypots.
The declarative form API derives its tool schema from a form’s fields, as described in the W3C declarative explainer (2026). How hidden inputs should be handled is still an open question in the specification, and in the behaviour Fusion Computing observed while building, a hidden honeypot field was treated as an ordinary field.
The failure runs like this. An agent reads the derived schema, sees the honeypot listed as a legitimate parameter and fills it. The backend sees a filled honeypot, classifies the submission as bot traffic and discards it. Most honeypot implementations return success so the bot learns nothing, which means the agent reports that the enquiry was sent. No error is raised anywhere.
The fix is to register the contact tool imperatively in JavaScript, building the payload directly so the honeypot stays empty by construction. The spam control keeps working against actual bots.
The second finding is a performance tax. Tool definitions tend to import the code that implements them, so mounting an agent surface globally can pull calculation engines into the bundle for every page. Fusion Computing measured 1,079 KB of eager client JavaScript on a service page with no calculator on it, across 13 script chunks.
That fell to 699 KB across 11 chunks once the surface was changed to detect agent support first and load the tools only when something is there to call them. That is a 35% reduction on a page that never needed the code. The naive build taxes every human visitor to serve a tiny minority of agent sessions.
The third finding is our own firewall rule. It rejects any request body containing a literal script tag, which stopped both the content-management API and the direct file-write path. The fix was to attach the code through the platform’s own script-enqueue function so no raw tag ever travels in a request body.
The fourth is smaller and easy to miss. Sites that force trailing slashes will answer a connector URL with a 308 redirect. Method and body survive that redirect, so well-built clients recover, though the endpoint should be published in its canonical form.
The WebMCP security risk businesses should understand
Researchers at National Yang Ming Chiao Tung University (2026) documented two attack families against WebMCP tool surfaces. Tool hijacking alters the set of tools an agent can see, using registration races or the abort mechanism. Tool framing changes how an agent understands a tool it already trusts. Against three frontier models, hijacking drove malicious invocation in 94% to 100% of trials.
The precondition for both attacks is an attacker achieving arbitrary JavaScript execution on the page, in practice by compromising or injecting into a third-party script the site already loads.
Running third-party JavaScript does not mean a site is compromised. It means every additional script supplier is one more dependency that could satisfy that precondition if it were breached. Analytics, session recording, chat widgets, marketing automation and advertising pixels are all third-party code running in the same context as the tool surface, and each vendor is a supply chain nobody controls.
| Attack family | What it does | Malicious invocation | Task still completes |
|---|---|---|---|
| Tool hijacking | Changes which tools the agent can see | 94% to 100% | 17% to 18% |
| Tool framing | Changes how the agent reads a trusted tool | 36% to 61% | 81% to 85% |
Why task completion can hide tool poisoning
In the NYCU study (2026), framing attacks preserved 81% to 85% task completion while hijacking preserved only 17% to 18%. That could make framing harder to notice, though the study did not test whether users detect it.
Book a script inventory before you expose any tool to an agent →
Why Canadian firms bring this work to Fusion Computing
CISSP-led, securing IT for Canadian SMBs across Toronto, Hamilton, and Metro Vancouver since 2012.
Any system where a model reads a description and decides what to call has the same weakness, so Fusion Computing treats tool metadata as untrusted input.
The study has limits. It used a WebMCP polyfill and a headless agent rather than native Chrome, and ran no test of whether people notice. The direction is credible; the exact numbers are not a production measurement.
What to do if you are considering WebMCP
The NYCU authors recommend four controls: bind tool identity to its origin, invalidate agent plans when the tool set changes, restrict third-party tool access to sensitive data by default, and keep traceable logs of registration and invocation events. The W3C specification (2026) adds a permissions-policy gate called tools, which defaults to a same-origin allowlist.
Three practical steps carry most of the value for a business without a dedicated application security team.
- Assert your own tool list at runtime. A page knows which tools it registered. Anything else appearing on the surface is either a bug or an attack. Treat that check as telemetry rather than a control: under this threat model the attacker already runs JavaScript on the page and could tamper with an in-page monitor, so the signal is only trustworthy once it is recorded somewhere outside the page.
- Keep the annotations truthful. A tool that writes to a CRM must never be marked read-only. Agents make decisions on those hints, and a false one is the framing attack performed by the site against itself.
- Never annotate a form that contains a honeypot. Build write-capable tools in code so hidden anti-spam fields cannot reach the schema.
Should a Canadian SMB do this yet?
The two halves carry different verdicts, and ours changed after five weeks. The browser layer depends on a Chrome origin trial documented by Google (2026) as running from Chrome 149 through Chrome 156, which makes it a time-boxed experiment rather than settled infrastructure.
The public MCP server is the half we took down, on 2026-09-30. Any MCP client could reach it and it needed no origin trial. In five weeks no enquiry came through it, and the people who found us through AI assistants arrived through our pages.
That fits how assistants work. They recommend a business from its pages, reviews and search results, and they only call a website’s MCP server when someone has added it as a connector.
Where an MCP server does pay is inside the business: connecting your team’s assistant to a system it cannot reach today, behind your own sign-in. That is a different job, and it is MCP server development.
The browser layer earns its place where a site already has interactive tools worth calling and a front end maintained by someone who will notice a regression. A brochure site with a contact form gains close to nothing and still inherits the security surface. Fusion Computing built it because it runs seven calculators and assessments that agents can usefully operate, and because implementing a standard is the only way to speak about it from evidence.
The standard is not ratified. Firefox and Safari have not committed. Treating this as an experiment with a real security review attached is the proportionate response, and treating it as a marketing checkbox is how the honeypot defect ships to production.
Sources
| Source | Supports |
|---|---|
| W3C Web Machine Learning Community Group, WebMCP specification draft, read 2026-08-26 | API surface, the tools permissions policy default, security considerations |
| W3C WebML CG, WebMCP explainer and declarative explainer, read 2026-08-26 | Headless browsing as a non-goal, declarative form API status |
| Google, Join the WebMCP origin trial, Chrome for Developers, read 2026-08-26 | Chrome 149 to 156 trial window, brands experimenting with WebMCP |
| Google, WebMCP documentation, Chrome for Developers, read 2026-08-26 | Scope of the API to in-browser agents |
| Lee, Chang, Yu and Yeh, National Yang Ming Chiao Tung University, WebMCP Tool Surface Poisoning, arXiv:2606.06387v1, 2026-06-04 | Attack taxonomy, invocation and task-completion rates, stated study limitations, recommended controls |
| OpenAI bot documentation, read 2026-08-26 | OAI-SearchBot and GPTBot roles |
| Anthropic crawler documentation, read 2026-08-26 | Claude-SearchBot and ClaudeBot roles |
| Fusion Computing deployment record, fusioncomputing.ca, 2026-08-26 | The four first-hand findings and the 1,079 KB to 699 KB measurement |
The short version
Skip the public MCP server on a marketing site; ours brought no enquiries in five weeks. Treat the browser layer as a scoped experiment with a review date, and only on a site with tools worth calling. Inventory the third-party scripts on the page before either. Never annotate a form that hides a honeypot.
Fusion Computing helps Canadian businesses across Toronto and the GTA, Hamilton, and Metro Vancouver with managed IT, cybersecurity, and Microsoft 365.
Frequently Asked Questions
What is WebMCP in simple terms?
WebMCP is a browser feature that lets a website offer an AI agent a set of clearly labelled actions it can perform, such as running a quote or submitting an enquiry. The site publishes each action with a name, a description and a defined set of inputs, so the agent calls it directly instead of interpreting the page visually.
Is WebMCP the same thing as MCP?
They share a design but run in different places. MCP describes how an AI assistant connects to tools on a server, which works from anywhere. WebMCP puts that same idea inside the browser tab, so the tools run in the visitor’s own session with their existing login.
Does WebMCP improve SEO or AI search visibility?
No. WebMCP has no effect on search rankings or AI search citations. Search crawlers such as OAI-SearchBot, Claude-SearchBot and PerplexityBot fetch and index HTML, while a WebMCP tool only exists inside a loaded browser session after the page registers it. The specification also names headless browsing as an explicit non-goal. Any vendor selling WebMCP as a visibility upgrade is describing something the standard does not do.
Talk to a CISSP-led team that has already shipped this standard →
Which browsers support WebMCP?
Chrome supports WebMCP through a public origin trial spanning Chrome 149 to Chrome 156, which a site opts into with a token. Microsoft Edge runs its own separate public origin trial for WebMCP and co-authors the specification. Chromium’s implementation record currently lists no signal from Gecko (Firefox) or WebKit (Safari). Browsers outside the trial ignore the code entirely.
Is WebMCP safe to add to a business website?
Treat it as a security project. Google’s own guidance says safety cannot be guaranteed inside a language model. The main risk is tool poisoning, where a compromised third-party script adds or reframes tools the agent trusts. Inventory the analytics, chat and advertising scripts on the page before any rollout, and build write-capable tools deliberately.
Does a small business need WebMCP?
Most small businesses do not need the browser half yet. It earns its place on sites that already run calculators, quoting tools or assessments worth calling. A brochure site with one contact form gains very little, and a public MCP server on our own marketing site brought no enquiries in five weeks.
What is the difference between WebMCP and a remote MCP server?
A remote MCP server runs on a server and answers AI assistants that have added it as a connector, using credentials you control. WebMCP runs inside the visitor’s browser and acts in their session with their login. A server suits connecting your own team’s assistant to your own systems. The browser layer suits people already using an agentic browser on your site.
