# In Your Product, the Agent Should Be the Guest

**WebMCP for B2B SaaS: what to expose, what to withhold, which categories move first — and the rename that quietly broke our own implementation.**

Checked: 27 August 2026 · auxfirst
Canonical: https://auxfirst.com/news/webmcp-b2b-saas.html

| | |
|---|---|
| Standard | Draft · W3C Web Machine Learning CG |
| Chrome | Public origin trial |
| Current API | `document.modelContext` |
| Checked | 27 August 2026 |

---

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`. 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.

## What we changed — not a rename, a different registration shape

**Was** — batched, on `navigator`:

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

**Now** — one call per tool, on `document`:

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

The commentary calls this a rename. It is not: the batched `provideContext({tools:[…]})` call became a per-tool `registerTool()` that also takes a second options argument for cross-origin exposure. Our page now feature-detects the current API, falls back to the legacy shape where that is what the browser implements, and does nothing at all where neither exists. The `readOnly` annotation is new too — it helps an agent decide when to ask for confirmation.

## 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. 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.

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.

## 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.

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. Google's phrasing, verbatim: *"Instead of your application being a guest within an agent, the agent is a guest on your platform."*

| | Server-side · MCP or API | In-browser · WebMCP |
|---|---|---|
| Who holds the interface | The agent | Your page |
| Lifetime | Persistent, headless, always available | Ephemeral — tools exist only while your page is open |
| You keep | The data, the business logic, the bill | The interface, the permission model, the surface area |
| You give up | The interface, the context, the reason anyone remembers your product | Reach when the tab is closed |

Google's guidance is not to choose. MCP is the persistent, headless service layer for background work; WebMCP is the contextual in-browser layer for while the customer is actually looking at your product. The recommendation is to run both. The distinction that matters commercially is which one is load-bearing for your renewal.

## 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."* 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. It provides **discovery**, **JSON Schemas** (to reduce hallucination or misunderstanding), and **state**.

Status as of 27 August 2026, without the hype:

- A draft under the W3C Web Machine Learning Community Group, co-authored by Google and Microsoft engineers.
- Chrome runs it as a public origin trial. Google states plainly that the API is under active discussion and subject to change — and the registration surface has already moved once.
- **Angular has experimental support for WebMCP.** 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."*
- The APIs are *"gated by both origin isolation requirements and permissions policy"*, and WebMCP is only available in origin-isolated documents.

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

Read that third one twice. WebMCP is not a discovery channel. It does not bring agents to your product. It determines what happens when the agent your customer *already pays for* arrives at a screen they already log into. That makes this a retention and expansion play, not an acquisition one.

## Why SaaS is the stronger fit, not the afterthought

Google's own use-case documentation includes 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*. Another is complex filtering across sites with hundreds or thousands of listings — housing rentals, hotel booking, ticketing. A third is a warranty claim, tooled end to end.

Those are not shops. They are consoles.

**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 fairly legible. 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 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. Fit 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.**

| Tier | Categories | Why it lands here | Where to start |
|---|---|---|---|
| **1 — build now** | CPQ & Quote-to-Cash · CRM & Sales Engagement · Marketing Automation · ERP, Accounting & Subscription Billing · Project Management & Help Desk · BI & Product Analytics · Contract Lifecycle & E-Signature · PIM, DAM & CMS | Configuration-heavy, browser-bound, high friction. Many interdependent fields, rules an agent cannot infer from the DOM, and a correct answer that depends on who is logged in. | The one workflow your customers complain about in every QBR. |
| **2 — read-only first** | IAM, PAM & SSO · Non-Human Identity Management · SIEM, DLP & Vulnerability Management · Incident Response · Payment Processing & Fraud · Payroll & HR data | Browser fit is good; the blast radius demands restraint. An agent inheriting an administrator's session in an IAM console is the highest-consequence version of this entire technology. | Tools that retrieve and explain. Hold every write tool until the evals are real. |
| **3 — use MCP instead** | CI/CD · Container Orchestration · MLOps · Data Labeling · Notification Infrastructure · Backup | The work is not browser-bound. Tools that exist only while a tab is open cannot serve a nightly job. | An MCP server. Then WebMCP later, for the console on top. |

**This tiering is our reading, not a measurement.** Unlike the [Agent Supervision Register](https://auxfirst.com/news/agent-supervision-register.html), nothing here is scored against a vendor page. The axes are the part worth keeping: browser-boundness decides whether WebMCP applies at all, and blast radius decides whether you start with tools that read or tools that write.

**Digital Adoption Platforms** deserve their own note: the category exists to help humans navigate complex software. When the navigator is an agent, the premise changes — either it becomes the layer that declares tools on behalf of applications that have not done it themselves, or it gets designed out.

**A signal from the taxonomy itself.** G2 now carries categories that did not exist eighteen months ago — Agentic AI, AI Agents, agentic browser software, MCP server infrastructure, Non-Human Identity Management, AI governance. The buyer-side vocabulary is forming right now.

## Session inheritance: the feature and the exposure

WebMCP needs no authentication of its own. It reaches live session data, cookies and DOM elements that are available only in a live browser tab. The agent inherits your customer's identity, tenant, role, entitlements and feature flags — with no new credential to issue, store or rotate.

**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.

**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.

**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. 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.

## 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. 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.

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. **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. A storefront has this problem in reviews; a B2B console has it in the primary workflow.

Three mitigations, all decisions rather than code:

- Mark any tool returning user-generated or externally sourced data with the **untrusted-content hint**.
- Mark tools that do not change state as **read-only**, so the agent can decide when confirmation is needed.
- Use the mechanism for **requesting user interaction during tool execution**, so consequential actions pause for a human.

We run this as the [Action Heat Ladder](https://auxfirst.com/action-heat-ladder.html) — 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

**Write for a model, not a developer.** The agent chooses a tool by reading its name, description and schema. Google's failure taxonomy: 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.

**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.

**Design output for the next call, not for a log.** Verbose output degrades the whole chain.

**Expect to iterate descriptions more than code.** The tool usually works. The agent's decision about whether to use it is what needs tuning.

### Character budgets — Chrome's recommended limits

| Field | Limit | Why it matters in a large product |
|---|---|---|
| Tool description | 500 characters | The agent picks your tool by reading this. The single highest-leverage string in the surface. |
| Parameter description | 150 characters | Where natural language becomes a typed argument. Vague here means wrong arguments there. |
| Tool and parameter names | 30 characters | Unambiguous across a 200-tool product, short enough to survive the budget. |
| Individual tool output | 1.5K characters | Output that feeds the next call has to be readable by a model, not a log parser. |

Chrome's stated purpose is to avoid running into agent guardrails, with the caveat that there is likely variation across agents. Enterprise products need to feel this constraint *before* enumerating tools: 200 tools × 500 characters is a context problem, not a documentation problem.

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

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 is evaluations.

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:

`start_pizza_creator` → `set_pizza_style` → `set_pizza_size` → `start_checkout` → **`add_discount_coupon` (FAILED)** → `complete_checkout`

`add_discount_coupon` failed, but the process was still able to complete. The user got the outcome, minus the thing that failed, and was not told. Translate that into your product — a permissions change where the scope restriction did not apply, a billing configuration where the proration rule did not fire, a data export where the redaction step was skipped — and you have the shape of an incident review rather than a bug report.

What to evaluate, per Google: that the model understands each tool's purpose from its description and schema; that it selects the right tool with the right parameters; that it acts on information a tool returned; and that a full user journey completes. Deterministic tests still cover everything that does not touch the model.

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. And **build datasets with both direct and open-ended queries**, because "add pepperoni" and "put all the meat on it" test different things.

## A ninety-day shape

**Weeks 1–3. Decide what you are defending.** Which jobs in your product would a customer's agent most plausibly try to do *without* you, and what happens to your position if it succeeds. Pick three. **Not the three that are easiest to build** — the three most load-bearing for renewal.

**Weeks 3–6. Design the surface for one of them.** Names, descriptions, schemas, state conditions, read-only flags, untrusted-content flags, the `exposedTo` list. Written down, reviewed, owned. **Treat it as an interface specification**, because that is what it is.

**Weeks 6–9. Build behind a feature check.** Feature-detect the API and degrade to nothing when it is absent. Cloudflare's bridge does the same: if the browser has no WebMCP surface it returns and does nothing. **Detect the current API and the legacy one** — that is the mistake we made.

**Weeks 9–12. Evals, confirmation policy, decision.** Score the journeys. Set human checkpoints by consequence and reversibility. Then decide: a maintained product surface with an owner and a changelog, or an experiment you shelve with a written record. **Either outcome is fine. Drifting between them is not.**

## 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.**

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 is explicitly a reading, not a measurement, and is labeled as such.

## Sources

**Chrome for Developers — fetched and verified 27 Aug 2026**
1. Alexandra Klepper — *WebMCP*. Published 18 May 2026, last updated 7 Aug 2026. https://developer.chrome.com/docs/ai/webmcp
2. André Cipriani Bandarra and Alexandra Klepper — *When to use WebMCP and MCP*. https://developer.chrome.com/docs/ai/webmcp/compare-mcp
3. Julia Pagnucco and Alexandra Klepper — *WebMCP tool security*. https://developer.chrome.com/docs/ai/webmcp/secure-tools
4. Alexandra Klepper — *How WebMCP fits in user journeys*. https://developer.chrome.com/docs/ai/webmcp/use-cases
5. Kasper Kulikowski — *Evals for WebMCP*. https://developer.chrome.com/docs/ai/webmcp/evals

**Platform implementations**
6. *WebMCP support for Liquid and Hydrogen storefronts* — Shopify developer changelog, 5 Aug 2026. https://shopify.dev/changelog/webmcp-liquid-hydrogen
7. *Give any website a WebMCP interface* — Cloudflare Blog, 6 Aug 2026. https://blog.cloudflare.com/webmcp/

**Standard and taxonomy**
8. *WebMCP explainer* — W3C Web Machine Learning Community Group. https://github.com/webmachinelearning/webmcp
9. *Browse All Categories* — G2, retrieved 27 Aug 2026. https://www.g2.com/categories

**Related on auxfirst**
- The Agent Supervision Register. https://auxfirst.com/news/agent-supervision-register.html
- AI layers name index. https://auxfirst.com/news/ai-layers-name-index.html
- The Action Heat Ladder. https://auxfirst.com/action-heat-ladder.html
- Agent-first API design. https://auxfirst.com/news/agent-first-api-design.html
- What is agent operability? https://auxfirst.com/news/what-is-agent-operability.html
- The agent development lifecycle. https://auxfirst.com/agent-development-lifecycle.html
- The Agent Operability Audit. https://auxfirst.com/agent-operability-audit.html

---

*Emil Krzemiński is the founder of auxfirst (https://auxfirst.com/), the agentic experience design agency. For how machines read auxfirst — including the two WebMCP tools this article is about — see https://auxfirst.com/ai-info.html.*