WebMCP: the store page

Some stores give agents a second way in: tools registered by the store's own web page, through WebMCP. UCP Playground can run an agent through those page tools and show them beside the store's UCP tools, so you can see what each route offers.

What WebMCP is

WebMCP is a draft web standard. A page registers tools on document.modelContext: each has a name, a description, an input schema and optional hints such as readOnlyHint. An agent working in the browser lists those tools and calls them, and the page does the work: searching, adding to the cart, moving to checkout. Normally that happens in the shopper's own browser, on the page they have open.

Shopify serves WebMCP tools on its Liquid storefronts, so many Shopify stores have page tools as well as a UCP endpoint.

{
  "name": "search_catalog",
  "description": "Search the store's products.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "catalog": {
        "type": "object",
        "properties": {
          "query": { "type": "string", "description": "What to search for" }
        },
        "required": ["query"]
      }
    },
    "required": ["catalog"]
  },
  "annotations": { "readOnlyHint": true }
}

An illustrative page tool, as the Inspector lists it. The name, schema and hints come from the page; nothing is added.

How it differs from UCP

• Where the tools live -- UCP tools sit at an endpoint the store declares in /.well-known/ucp and are called over MCP or REST. WebMCP tools live in the page and only exist once the page has loaded in a browser.
• Whose session -- a UCP checkout is created by the agent through the store's API. A page tool acts on the page's own cart and checkout, the same ones a shopper sees.
• What is described -- UCP has a manifest, versions and capabilities to negotiate. A page simply registers whatever tools it has.

Run a store-page task on the Agent page

On the Agent page, connect the store as usual. The endpoint card then shows a Connection picker: UCP · MCP, UCP · REST, and under Store page, WebMCP. Choose WebMCP and send one task, for example "add a black tee in M to the cart and go to checkout".

The agent opens the store's home page in a browser on our side and uses the tools that page registers. If the page has no WebMCP, or registers no tools, the run says so and stops. The buyer context you set (country, currency, language) is applied to the page before it loads.

• Signed in only -- the WebMCP option appears when you are signed in. It is not offered in Shop All Stores.
• One task per run -- there are no follow-up messages. When the run ends, click New run for the next task on the same store.
• Daily limit -- 10 store-page runs per user per day, reset at midnight UTC.
• Never pays -- cart tools run, so the run can build a real cart. It stops when the page reaches the store's checkout. Tools that pay, place an order or are marked as having real-world consequences never run.
• Busy browsers -- if every browser is in use when you send, the run waits briefly for one and the page tells you it is waiting.

During the run you see the page the agent opened and, when it gets there, the checkout where it stopped. Runs are saved to your history like any other session. Their results stay with you: store-page runs are not part of the public leaderboard.

Screenshots and replays

A store-page run takes screenshots of what a shopper would see: the page it opened, the page after each step that changes it (the cart page after a cart change, or a page a tool moved to), and the checkout it reached. They appear under each step in the replay, in Session History and on the shared page once you share the session, and they are kept with the session. At the checkout, the replay also shows What the checkout page showed: the text of the store's checkout page.

Inspect a page's WebMCP tools

In the Inspector, connect a store and click WEBMCP beside the MCP and REST buttons. The Inspector loads the store page in a browser on our side and shows:

• Page facts -- the HTTP status, whether document.modelContext is present, how many tools the page registered, and the store's UCP version.
• Page tools vs UCP tools -- a table matched by job (search the catalogue, product details, add to cart, read the cart, checkout, policies and so on), with the page's tools in one column and the UCP endpoint's tools in the other. A dash means that route has no tool for the job. If the store's UCP tools can't be listed, the table shows only the page's tools and says why.
• Each tool -- its description, a read-only or changes state label, a parameter table (object parameters are opened one level), and the raw input schema.
• Findings, not grades -- notes on each tool, such as no readOnlyHint, a tool marked read-only whose name says it changes something, parameters without a description, a description carrying instructions aimed at the agent, or a tool that declares its results contain text the merchant wrote.

Choose a tool to run it. Only tools marked read-only run in the Inspector; anything that changes state is shown but not run. The result shows the time taken, the raw reply and, if the page moved, the page it ended on.

What a merchant can learn from the two routes

Run the same task over UCP and over the store page, with the same model, and compare the two replays:

• Coverage -- which jobs each route can do, and whether an agent can get from search to checkout through both.
• Tool quality -- whether page tools carry clear descriptions and the right hints, so an agent knows what is safe to call.
• Price and checkout -- whether the checkout an agent reaches through UCP matches the one on the page: the same item, price, currency and shipping. The store-page run's screenshots and checkout page text show what a shopper would actually see.
• Behaviour -- how many steps each route takes, and where each one stops or fails.

Agents on both routes treat text in tool replies written by the merchant or third parties as information, not instructions. A tool's own guidance on which tool to call next is followed.

See Agent Runs for the Connection picker and Endpoint Discovery for how the UCP side is found.