Tool Inspector

The tool inspector lets you browse, understand, and manually call every MCP tool a store exposes. It is the fastest way to learn what a store supports before running an agent session.

Browsing Tools

After connecting to a store through endpoint discovery, the Inspector issues a tools/list JSON-RPC call to retrieve the full set of available tools. Each tool is displayed with:

• Name — The tool identifier used in JSON-RPC calls, such as search_shop_catalog or create_cart.
• Description — A human-readable explanation of what the tool does and when to use it.
• Input schema — The full JSON Schema defining required and optional parameters, their types, and validation constraints.

The input schema is especially useful. It tells you exactly what arguments a tool accepts, which ones are required, and what formats they expect. For example, a checkout tool might require an idempotency-key as a UUID, while a search tool might accept optional filters and pagination objects.

Trying a store

No store in mind? The connect form offers a row of try-target pills with known-good stores. Two are tagged as test stores, demo merchants hosted by the harness where every tool works end to end: flower-shop.local for shopping and hotel.local for lodging. One click connects and lists its tools.

Transports and the WebMCP view

Buttons above the results switch between the transports the store declares: MCP lists the tools and lets you call them, REST gives you a search, product cards and a cart, and A2A is shown as declared but not connected to. The WEBMCP button shows a different thing: the tools the store's own web page registers, beside the store's UCP tools. It is not a UCP transport. See WebMCP: the store page.

Lodging stores

A store that declares the dev.ucp.lodging service (the draft lodging booking capability, dev.ucp.lodging.booking) gets a booking flow instead of a product search: Search for stays, pick a Rate, Review the booking session, and Book. It works over MCP and REST.

Review shows the booking session exactly as the store returned it: its status, the price breakdown (totals), when each amount is paid (payment.terms -- due today, later, or at the property), the cancellation policy with its refundability, and the store's messages. Errors say what the store still needs, such as the booker; disclosures, such as a local tax, are shown in full. Confirming asks you to acknowledge the disclosures first, and hotel.local takes test cards (tok_visa approves, tok_decline declines).

Discovery is outside the lodging capability, so hotel.local provides its own search_properties tool and labels it as not part of UCP.

Calling Tools Manually

You can invoke any tool directly from the inspector by filling in arguments and submitting the call. The Inspector sends a tools/call JSON-RPC request and displays both the raw request and response.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_shop_catalog",
    "arguments": {
      "query": "blue running shoes",
      "limit": 5
    }
  }
}

The raw JSON-RPC exchange is visible in the debug panel, making it straightforward to diagnose issues like malformed arguments, missing required fields, or unexpected error responses.

Common UCP Tools

Most UCP-compatible stores implement a standard set of tools for the full shopping lifecycle:

• search_shop_catalog — Search products by keyword, filters, and pagination. Returns product summaries with pricing and availability.
• get_product_details — Fetch complete product information including all variants, options, images, and inventory status.
• create_cart — Start a new cart with one or more line items. Returns a cart ID for subsequent operations.
• update_cart — Add, remove, or change quantities of items in an existing cart.
• create_checkout — Initialize a checkout session from a cart. Returns the checkout state with totals, shipping options, and required fields.
• complete_checkout — Finalize a checkout with payment details and buyer information to place the order.

Some stores expose additional tools like get_cart, cancel_cart, get_checkout, update_checkout, and cancel_checkout for more granular control over the flow.

The Health Check panel

The rail beside the tool list carries a Health Check panel grading the store's manifest: a letter grade plus a passing-checks ratio (e.g. 9/11) in the header, and beneath it the individual checks, each marked pass, warn, or fail. The checks cover manifest structure -- version format, declared services and their transport endpoints, capabilities and their versions, reverse-domain naming, payment handlers, signing keys. Warns count half toward the grade; expand the panel to see exactly which check is dragging it down. (Tool schema grading is separate -- see Schema Quality.)

Buyer context, held state, and negotiation

Three more panels sit on the rail, and the same three appear on the Agent page:

• Buyer context -- the spec's provisional buyer signals: address_country, address_region, postal_code, language, currency. Set them once (the pill opens an inline editor; Settings holds the durable copy per account or workspace) and every catalog search carries them where the merchant's tool accepts them: inside catalog.context on the Shopify-shaped search_catalog, as a top-level context object where a tool's schema declares one, and on the REST POST /catalog/search. They are hints for localisation, not identity. The Inspector reflects the merchant's answer -- some stores return local currency, others ignore the hint and say nothing.
• Held state -- a ledger of what merchants are holding for you. When a tool call creates or updates a cart, opens a checkout session, or holds an offer, the merchant's response is mirrored into one row per merchant and kind, with the merchant's own totals, line items, continue link, expiry, and any warnings it sent as a note. A live countdown runs from the merchant's expires_at; an expired hold or a failed call flips the row to stale. Forget drops our mirror only and never contacts the merchant. Nothing is computed here: if the merchant returned no line items, the row says so.
• Negotiation -- the readout of the connect handshake in five steps: discover the manifest, select a version, intersect the declared capabilities with the ones this platform supports, resolve extension blocks, activate the prompt variant. Every capability row is marked active, passthrough, or excluded with a reason, including a version the platform does not run. Spec capabilities and vendor extensions are distinguished.

The same thing, headless

Everything the Inspector does interactively is also three API calls, gated by the inspect token ability:

• POST /api/v1/inspect/discover -- resolve a domain's manifest to endpoints and capabilities, plus the same negotiation readout the panel shows
• POST /api/v1/inspect/tools -- list an endpoint's tools with the same schema-quality grade
• POST /api/v1/inspect/call -- call one tool by hand and get the raw result

See the API Reference for request shapes and examples.