WebMCP: the store page

Some stores give agents a second way in: tools registered by the store's own website, through WebMCP. UCP Playground can send an agent through those website 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 website 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 website tool, as Inspect 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 cart: a UCP checkout is created by the agent through the store's API. A website tool acts on the page's own cart and checkout, the same ones a shopper sees.
• What is described: UCP has a profile, versions and capabilities to negotiate. A page registers whatever tools it has.

Run a task through the store's website

On Runs, with the store chosen, set the How the agent reaches the store pill to Website and send one task, for example "add a black tee in M to the cart and go to checkout". If the store has no UCP profile, Check the store's website looks for website tools first and, when it finds some, sets the run to go through the website.

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 details you set (country, currency, language) are applied to the page before it loads.

• Signed in only: the Website option appears when you are signed in.
• One task per run: a website run is one task in its own browser, with no replies. Start a new run to ask something else.
• Daily limit: 10 website 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.

Website runs are kept in History like any other run. Their results stay with you: website runs are not part of the public leaderboard.

The agent's browser

A website run's page has a third pane, The agent's browser, with screenshots of what a shopper would see: the page it opened, the page after each step that changed it (the cart page after a cart change, or a page a tool moved to), and the checkout it reached. Choose a screenshot to find its step in the trace, and play the run back with the replay bar to watch them in order. Screenshots are kept with the run, and appear on its shared page once you share it.

Inspect a website's tools

In Inspect, choose WebMCP as the transport. Inspect opens the store in our browser, lists the tools its website registers, and lets you call them like any other tool, each call kept in the trace. Only tools marked read-only run; anything that changes state is shown but not run.

The public Inspector has a fuller WEBMCP view beside its MCP and REST buttons. It 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. 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 through the Website, with the same model, and compare the two runs:

• Coverage: which jobs each route can do, and whether an agent can get from search to checkout through both.
• Tool quality: whether website 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 website: the same item, price, currency and shipping. The website run's screenshots 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 starting a run and Endpoint discovery for how the UCP side is found.