In your product, the agent should be the guest

Our own homepage has been registering WebMCP tools since the spring. Two of them: one that returns what auxfirst does, one that prepares an enquiry and hands back the contact URL. We wrote about doing it. We put it in our AGENTS.md. We were quite pleased with ourselves.

They registered on navigator.modelContext. Chrome's documentation now uses document.modelContext.^[3] Our feature detection asked whether modelContext existed on navigator, found that it did not, and returned cleanly — exactly as designed. No error. No console warning. No broken layout. Two tools that did nothing, for weeks, and the failure was invisible by construction.

That is a small embarrassment and a useful one, because it is the whole subject of this piece in miniature. Agent-facing surfaces fail silently. They have no users to complain, no error page, no support ticket. If you do not test them deliberately, you find out when someone else does.

navigator.modelContext.provideContext({
  tools: [ toolA, toolB ]
});

document.modelContext.registerTool({
  name: "get_auxfirst_capabilities",
  description: "…",
  inputSchema: { … },
  annotations: { readOnly: true },
  execute: async () => ({ … })
});

Ecommerce already resolved. Your product has not.

Most WebMCP coverage this year has been about shopping. That is a reasonable place to start a demo and a bad place to stop thinking, because ecommerce is the part of this story that settled itself in a single week.

On 5 August 2026 Shopify turned WebMCP on across its storefronts. The changelog is unambiguous: agents can search your catalog, manage the shopper's cart, and go to checkout on the shopper's behalf, all in the tab they're looking at — and the tools are live today on every Liquid storefront and on the Hydrogen developer preview, with nothing to install or configure.^[6] One day later, Cloudflare shipped a preview that gives any site behind it a WebMCP surface from the dashboard, bridging an existing MCP server into the page if you have one.^[7]

So in retail, the tool surface arrived as a platform default, identically, for everyone. Nobody is going to do that for your SaaS product. Which is the point, and the opportunity.

If you want the commerce-side version of this argument, it lives in agentic commerce and recommended by AI, impossible to buy from. The rest of this piece is about consoles, not shops.

The disintermediation question, stated properly

You have two ways to make your software usable by an AI agent, and they point in opposite directions.

The first is server-side: an MCP server, or an API. The agent connects, pulls data, calls functions, and renders whatever interface it likes. Google's description of the trade-off is unusually direct — with that model your application's UI is rendered inside the agent's UI and has to conform to its constraints.^[2]

Follow that to its end state. Your workflow logic, your guardrails, your onboarding, your upsell surfaces, your reporting, the accumulated design judgment of a decade — all of it becomes optional. The customer's agent becomes the interface. Your product becomes a database with an invoice attached, and the renewal conversation gets considerably harder.

The second is WebMCP. Your page declares its tools to the browser; the agent calls them inside the live tab, on the customer's session, while your interface stays on screen. Google's phrasing, verbatim: “Instead of your application being a guest within an agent, the agent is a guest on your platform.”^[2]

What WebMCP is, precisely, and where it stands

WebMCP is “a proposed web standard to help you build and expose structured tools for AI agents.”^[1] Two APIs: an imperative JavaScript one for registering tools with names, descriptions and JSON Schemas, and a declarative one that annotates standard HTML form elements so agents know how to interact with them.^[1] It provides three things — discovery, a standard way for pages to register tools such as checkout or filter_results; JSON Schemas, explicit definitions of inputs and expected outputs to reduce hallucination or misunderstanding; and state, so the agent knows what is currently available to act on.^[1]

Status as of 27 August 2026, without the hype:

• It is a draft under the W3C Web Machine Learning Community Group, co-authored by Google and Microsoft engineers.^[8]
• Chrome runs it as a public origin trial.^[1][5] Google states plainly that the API is under active discussion and subject to change — and the registration surface has already moved once.^[1]
• Angular has experimental support for WebMCP.^[1] It is the only framework Chrome documents as having support — React appears on the same page only as the stack behind one of the demos, which is a different claim.
• Tools are ephemeral: “They exist only when your page is open. Once the user navigates away from your site or closes the tab, the agent cannot access your site or take actions.”^[2]
• The APIs are “gated by both origin isolation requirements and permissions policy”, and WebMCP is only available in origin-isolated documents.^[1]

Google names three limitations directly, and two of them bite harder in SaaS than in retail. Headless browsing: it targets local browser workflows with a human in the loop.^[1] Complex sites: “If your site is highly complex, you likely need to refactor or add JavaScript to handle application and interface state.”^[1] And tool discoverability: “Clients and browsers must visit a site directly to know if it has callable tools.”^[1]

Why SaaS is the stronger fit, not the afterthought

Read Google's own use-case documentation and the retail framing falls away fast. One worked example is a work-management software company adding a timesheet tool, so vendors and attorneys at a law firm can input timesheets with the right context and the company bills the correct department.^[4] Another is complex filtering across sites with hundreds or thousands of listings — housing rentals, hotel booking, ticketing — each with a unique combination of features.^[4] A third is a warranty claim, tooled end to end so the customer never has to find the form.^[4]

Those are not shops. They are consoles.

The structural reason is simple. WebMCP's advantage grows with the gap between what a screen can do and how obvious that is to a machine. A product page is a fairly legible thing. A permissions matrix, a segmentation builder, a pipeline stage configuration, a chart of accounts, a multi-condition automation, a quote with five interacting discount rules — these are dense, stateful, and specific to your domain. They are precisely where a screen-reading agent fails and where a declared tool wins by the largest margin.

And they are where your customer's frustration already lives. Nobody has ever said they wish their CRM had a faster product page. Plenty of people have said they have no idea how to build the report they need.

Which categories move first

Mapped against G2's software category taxonomy.^[9] Fit for WebMCP does not track category popularity. It tracks two things: how much of the value sits in a browser UI, and how bad it is if the agent gets it wrong.

Session inheritance: the feature and the exposure

The property that makes WebMCP practical in enterprise software is that it needs no authentication of its own. It runs on the browser session that already exists. WebMCP reaches live session data, cookies and DOM elements that are available only in a live browser tab.^[2] The agent inherits your customer's identity, tenant, role, entitlements and feature flags — with no new credential to issue, store or rotate.

The commentary calls this a shortcut around API keys. It is more interesting than that: your existing permission model becomes the agent's permission model automatically, which is the hardest problem in enterprise agent deployment, solved by construction rather than by project.

It also means the agent has exactly the reach of whoever is logged in. Two things follow.

Tools should be conditional on state. A logged-out visitor sees a small set. A standard user sees more. An administrator sees a different set again. This is not a security boundary — your server-side authorization remains the boundary — but it stops the agent attempting things the user cannot do and returning confusing failures.

Cross-origin exposure needs an owner. By default, other websites and cross-origin iframes cannot observe or interact with your tools; you open that deliberately with the exposedTo option, passing an array of specific, secure origins.^[3] Google's guidance is explicit about the asymmetry: a read-only tool can still reveal information about a user, so expose it only to origins you would share that data with anyway; read-write tools act on the user's behalf, so expose them only to origins you trust to act for your user.^[3]

For a multi-tenant platform with an embedded-partner story, that exposure list is a commercial decision with a security consequence. Somebody senior should own it, and it should be written down in the same place as your data-processing commitments.

The risk that is specific to B2B

Language models process instructions and data as one undifferentiated stream of tokens, which makes them susceptible to indirect prompt injection — malicious instructions inserted by an attacker into content the model reads.^[3] Google does not soften this: it is impossible to guarantee safety inside a model, there are repeatable prompt injection attacks against agentic systems built on state-of-the-art models, and the prevalence of these attacks on the web is increasing.^[3]

Now consider what a B2B console contains. Support tickets written by strangers. Form submissions. CRM notes synced from inbound email. Uploaded documents. Vendor records. Chat transcripts. Ticket attachments. Almost every high-value tool in a B2B product returns text somebody outside your company wrote.

An agent holding your administrator's session, reading a support ticket, following an instruction hidden inside it, and calling another of your tools is not a hypothetical. It is the obvious attack, and it aims at your most privileged users. A storefront has this problem in reviews; a B2B console has it in the primary workflow.

Three mitigations are available today, and all three are decisions rather than code:

• Mark any tool returning user-generated or externally sourced data with the untrusted-content hint, so the payload is explicitly labeled and the agent applies heightened scrutiny.^[3]
• Mark tools that do not change state as read-only, so the agent can make better decisions about when confirmation is needed.^[3]
• Use the mechanism for requesting user interaction during tool execution, so consequential actions pause for a human.^[3]

Deciding which of your actions run silently, which pause, and which are never exposed at all is a product and risk decision, not an engineering one. We run it as the Action Heat Ladder — actions ranked by consequence and reversibility, with the human checkpoint set accordingly. WebMCP is the first mainstream browser standard that makes that ladder directly implementable.

Designing the tool surface

Four things separate a tool surface that works from one that demos.

Write for a model, not a developer. The agent chooses a tool by reading its name, description and schema. Google's failure taxonomy makes the diagnosis concrete: when an agent skips a tool or calls the wrong one, the questions are whether the description is clear and complete, whether the function name is intuitive and descriptive, and whether the schema is too similar to another tool's, creating ambiguity.^[5] In a product with two hundred candidate tools, ambiguous naming is the default failure, not the edge case.

Constrain inputs with enums. When the agent calls a tool with wrong arguments, the fix is usually a better-defined input schema with explicit enumerated values and clear per-property descriptions guiding the mapping from natural language into structured data.^[5]

Design output for the next call, not for a log. If an output feeds a subsequent tool call it must be formatted for a model to ingest and contain the minimum essential information. Verbose output degrades the whole chain.^[5]

Expect to iterate descriptions more than code. The tool usually works. The agent's decision about whether to use it is what needs tuning — which is a writing problem living in an engineering backlog.

Mid-chain failure, and why evals are the acceptance criterion

You cannot ship this on a test plan. Google's position: to test any system using generative AI, your tests need to support probabilistic outcomes — “one input could lead to thousands of answers with varying degrees of accuracy” — and the technique for that is evaluations.^[5]

The failure that should worry a B2B product team most is the one nobody sees. Google's worked example runs six tools in sequence to order a pizza with a discount coupon. One of them fails. The process completes anyway.

Google's guidance on what to evaluate: that the model understands each tool's purpose from its description and schema; that it selects the right tool with the right parameters for a given intent; that it acts on information a tool returned, for instance to feed the next call; and that a full user journey completes.^[5] Deterministic tests still cover everything that does not touch the model.^[5]

Two practices worth taking directly. Test tools in isolation before running journeys — if the agent cannot pick the right tool for a simple request, it has no chance in a complex one.^[5] And build datasets with both direct and open-ended queries, because “add pepperoni” and “put all the meat on it” test different things: one tests execution, the other tests reasoning and tool selection.^[5]

This is the same discipline we argue for in can I prove what the agent did? and score across twelve platforms in the Agent Supervision Register — where the median supervision score across eleven scored platforms was 6 out of 12, and not one documented a way to reverse work an agent had performed. If the platforms your product sits alongside cannot reverse an agent's action, the bar for your own tool surface is higher than you would like.

A ninety-day shape

This is not a platform migration. It is a scoped design exercise with a decision at the end, and it should be treated as one — the same structure we use in the agent development lifecycle.

The part worth holding onto

The agent is coming into your product either way. The only question is whether it arrives as a guest you have prepared for — working inside the interface you designed, under the permissions you already enforce, calling the actions you chose to expose — or as a client of your API, rendering somebody else's interface over your data while your product team wonders why usage metrics stopped meaning anything.

WebMCP is a draft standard in an origin trial, with an API that has already been renamed once and documentation that says it is subject to change. Treating it as production infrastructure would be a mistake. Treating it as a question you can answer later is a bigger one, because the answer determines whether your interface still matters in your own category.

And test the thing you ship. We did not, for a few weeks, and two perfectly good tools sat there doing nothing while failing exactly the way they were designed to fail.

Method: every factual claim above traces to a page fetched on 27 August 2026 and quoted or paraphrased from it. Direct quotations are marked. Claims that could not be verified against a fetched page were removed rather than softened — including the specific tool names in Shopify's default set, which are not present in the fetched changelog text. The category tiering in Figure 2 and Table 1 is explicitly a reading, not a measurement, and is labeled as such.