---
title: 'WebMCP (in-browser agent tools)'
description: 'Every page of the storefront registers typed, page-contextual agent tools via document.modelContext — search, cart, per-product add-to-cart, declarative forms, even design-pack tools — on by default for webshop scaffolds, one flag for everyone else.'
canonical: 'https://cartwright.app/docs/features/webmcp'
---

# WebMCP (in-browser agent tools) (/docs/features/webmcp)



Where the [MCP server](/docs/architecture/mcp-server) lets *external* agents call your shop over HTTP, **WebMCP** brings agent tools into the browser tab itself. An in-browser AI agent (ChatGPT's built-in browser, a browser assistant) calls your storefront's declared tools directly instead of guessing at the DOM — and the tools are **page-contextual**: the product page sells its own product, the cart page edits its own lines.

It's gated behind `brand.features.webMcp` (runtime tier) and requires webshop mode. **Webshop templates** (`--template coffee | sunglasses | generic`) **scaffold with the flag ON — the store is WebMCP-native out of the box**; website-mode scaffolds ship the whole surface dormant until you flip the flag in `/admin/features` (no deploy needed). When off, nothing registers and the HTML is byte-identical.

<Callout type="warn">
  **Experimental, by design.** WebMCP is a W3C Web Machine Learning CG **draft** — supported today by Chrome (origin trial / `chrome://flags/#enable-webmcp-testing`) and ChatGPT's built-in browser. The namespace still moves (`document.modelContext`, with `navigator.modelContext` deprecated in Chrome 150); Cartwright feature-detects both and no-ops everywhere else.
</Callout>

## Three registration styles [#three-registration-styles]

1. **Imperative, per route.** Site-wide tools mount from the layout; page-contextual tools mount server-gated on the catalogue, product and cart pages. The server narrows exactly what each page knows (live variants, prices, stock, the filtered list) into the tool descriptor — the agent reads what the human sees, and tools appear/disappear with navigation.
2. **Declarative forms.** The search, contact and newsletter forms carry `toolname` attributes — the *form itself* is the tool, answered via `SubmitEvent.respondWith`. Autosubmit only on read-only search; the human confirms communication. The checkout form is deliberately **not** annotated.
3. **Design-pack tools.** A pack can ship its own (`DesignPack.webMcpToolBindings`) — the crema pack's homepage brew calculator doubles as `calculate_brew_ratio`, computed from the same math module as the visible widget.

## The tools [#the-tools]

| Surface        | Tools                                                                                                                                |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Site-wide      | `search_products` · `get_cart` (verification-rich returns: line handles, stock ceilings, structured money) · same-origin `navigate`  |
| Catalogue page | `list_visible_products` (exactly what the human sees, zero network) · `filter_products` (schema server-derived from live categories) |
| Product page   | `add_current_product_to_cart` (the page's product; variants + stock in the descriptor)                                               |
| Cart page      | `update_cart_item_quantity` · `remove_cart_item` · `go_to_checkout` (opens the page — nothing more)                                  |
| Forms          | `site_search` (autosubmit) · `contact_store` · `newsletter_signup`                                                                   |
| Design pack    | e.g. crema's `calculate_brew_ratio`                                                                                                  |

A **test-enforced safety moat** holds the whole browser surface to the cart/catalogue tool families — aggregated across every registration surface including design packs. *No order-placing tool exists in the browser*; checkout stays the human's. Every cart mutation returns the fresh cart so the agent verifies instead of assumes.

## What each profile ships [#what-each-profile-ships]

| Profile           | WebMCP                                                                                     |
| ----------------- | ------------------------------------------------------------------------------------------ |
| `light` (default) | Everything — ON when scaffolded with a webshop template, dormant behind the flag otherwise |
| `full`            | Everything, same rule                                                                      |
| `site` (static)   | Nothing — no runtime to register against                                                   |

## Trying it [#trying-it]

In Chrome 146+ enable `chrome://flags/#enable-webmcp-testing` — or just open the shop in ChatGPT's desktop-app browser. On a webshop (webshop templates scaffold with `webMcp&#x60; already on), visit &#x2A;*`/<locale>/webmcp-check`**: the full tool inventory grouped by surface (rendered from the same constants the moat test verifies), the safety model, and a live registration panel. For an origin trial, set `NEXT_PUBLIC_WEBMCP_ORIGIN_TRIAL_TOKEN` and the token is server-emitted into the document head.

<Cards>
  <Card title="MCP server" href="/docs/architecture/mcp-server" />

  <Card title="MCP tools" href="/docs/api/mcp-tools" />

  <Card title="UCP identity-linking" href="/docs/features/ucp-identity-linking" />

  <Card title="Feature flags" href="/docs/configuration/feature-flags" />
</Cards>