Product selection: help agents compare what actually fits

Consider the actual request: I want to upgrade from my current machine, I make two flat whites a day, and I have 32 centimetres of counter. Three constraints, spread across a specification table, a compatibility chart and a product description that mentions width in a footnote.

Answering that request requires the constraints to be available as data. A public scan can flag missing or unreadable product information; a browser test must check whether an assistant selects the right product.

Which shops this applies to

Many specifications per product, several of which are hard constraints rather than preferences.
Accessories with real compatibility rules — mounts, filters, cartridges, cables, sizes.
A basket large enough that a wrong choice is expensive to return.
Customers who already research across three tabs before buying.

Camera systems, espresso, PC components, car parts, prototyping electronics, professional audio, bike components, industrial fasteners. If your support inbox is full of will this fit my…, you are in this category.

A first tool set

search_products(query, filters)        // free text plus hard constraints
get_product_details(id)                // full specifications, typed
compare_products(ids[])                // side by side, differences highlighted
check_compatibility(productId, accessoryId)
get_cart() / add_to_cart(id, quantity)
apply_coupon(code)
get_my_orders()                        // only when signed in

compare_products and check_compatibility need reliable product data and explicit rules. A source scan can find public signals, but it cannot verify that either tool returns the right recommendation.

Conditional tools are the interesting part

A site could expose search, details and compatibility to signed-out visitors, then register cart and order tools only in an authenticated session. Implement and test those permissions explicitly; the public scan does not inspect a signed-in session.

A browser session avoids handing a separate API key to an assistant, but authorization, consent and data exposure still need review for every tool.

The prerequisites nobody wants to hear

Specifications as data, not prose. width: 31 cm in a field beats approximately 31cm wide in a paragraph. Emit it as a QuantitativeValue with a unit code — see structured data.
Compatibility as a relation. If the rule lives in a PDF chart, no tool can answer it. It has to be queryable.
Product pages that render server-side. A tool on a page an agent reads as blank is a tool nobody finds. See content without JavaScript.
No challenge on the cart path. A CAPTCHA between an agent and a checkout ends the session.

Payment is the step after

An agent that can research and fill a basket but not pay stops one move short. The rails — x402, the Agentic Commerce Protocol, the Universal Commerce Protocol — are young and choosing one is a real decision tied to your payment provider. Our scanner checks for these only when it detects commerce signals, and excludes them otherwise.

What it is worth

Treat conversion and returns as outcomes to measure, not as consequences of a scan score. Record a real product-finding task, test it before and after a change, and compare the result using your own analytics.

A useful baseline is to take ten frequent customer questions and count how many a machine can answer from the public product pages without reading a PDF chart. Check the exact product URL, then test the real comparison and cart flow in a browser. A source-level scan cannot prove that a purchase succeeds.