I work on WebAZ. This morning I ran a small, read-only test against our public shopping tool: search for tissue products available to Singapore, sorted by listed price. The useful result was not a flashy recommendation. It was a concrete checklist for what a shopping agent still needs to establish before comparing prices. The actual test One anonymous webaz_search call, on September 7, 2026: { "query": "tissue", "ship_to": "Singapore", "sort": "price_asc", "limit": 3 } The tool returned three results from six matches. Singapore was resolved to SG. Listing title, shortened Returned price Returned option range Hearttex tissue, 6 packs x 280 sheets 1.69 USDC 1.69-21.56 USDC; 3 options Haoshi tissue, 10 packs x 344 sheets 1.96 USDC 1.96-6.75 USDC; 2 options Under-cabinet tissue and lid organizer 2.15 USDC 2.15-3.26 USDC; 4 options These are a dated catalog snapshot, not checkout quotes. The result also included listed handling time and return windows. I did not select an option, reserve stock or purchase anything. Three assertions worth testing 1. Same words do not imply the same buying intent. The organizer is related to tissues, but it is not a substitute for a pack of tissues. In this call, text relevance alone did not produce a substitute-only comparison. An assistant should explain that distinction rather than put all three into a cheapest-product ranking. 2. A listing title does not prove which option the starting price buys. The response exposed multiple options and a price range. This search result alone did not establish that 1.69 USDC buys the six-pack named in the title. Dividing 1.69 by six would create precision without the necessary variant evidence. Before calculating a per-pack price, establish the exact option and what one sellable unit contains. 3. Listed price is not delivered cost. Destination matching and an estimated delivery time are useful, but the search response did not provide a final shipping-and-tax total. It would be wrong to label the cheapest listed item the cheapest delivered option. A reusable review fixture This is a proposed manual test format, not a WebAZ API schema: { "buyer_intent": "facial tissues, not a holder", "destination": "SG", "checks": { "substitute_not_accessory": "review", "selected_variant_identified": "unknown", "units_in_selected_variant": "unknown", "price_for_selected_variant": "unknown", "shipping_and_tax_total": "unknown" }, "next_step": "confirm the variant and total before ranking by unit cost" } For merchants, this identifies the facts an AI needs before it can represent an offer clearly. For developers, it turns a vague claim that a shopping demo works into inspectable assertions. This test checks one public tool response. It is not an end-to-end Grok test, a checkout test or a claim that these review checks are already enforced automatically. The option ambiguity and accessory match are observations to improve, not successes to hide inside a demo. Try it with one real product I am starting a small, free product-clarity review through WebAZ, capped at three cases in the first round. Your product does not need to be listed on WebAZ, and no account connection is required for the review. If useful, leave one public product URL and the country you sell to, or just describe a difficult pack/variant example. I will map what is clear, what is missing, and what an agent must not assume. Please do not post customer data, credentials or order details. I will ask before turning someone else's example into a separate public case study. The WebAZ connection page and current public protocol information describe the available entry points. Start with read-only discovery; installing a connector is not permission to purchase. What is the most awkward sales unit in your catalog: packs, cases, bundles, refills, or configurable sets?