A Shopping Search Result Is a Candidate, Not a Recommendation

When a shopping agent receives a successful catalog response, what has actually succeeded?

Not the purchase. Not necessarily the recommendation. Sometimes, not even relevance.

I work on WebAZ. While checking our public discovery example, a request for umbrella, with Singapore as the destination and fuzzy search enabled, returned three candidates: two tote bags and one umbrella. This is a useful limitation to disclose, not a precision-search success story. A response can be valid JSON and still need substantial filtering before it is useful to a buyer.

Start with a public, read-only request

This Node 18+ example only reads public product data. It does not need a wallet or credentials and cannot create an order or pay.

const url = new URL('https://webaz.xyz/api/products');
url.search = new URLSearchParams({
  q: 'umbrella', ship_to: 'SG', fuzzy: 'true'
});
const response = await fetch(url, {
  signal: AbortSignal.timeout(15000)
});
if (!response.ok) throw new Error(`Catalog HTTP ${response.status}`);
const body = await response.json();
const rows = Array.isArray(body) ? body :
  (body.products ?? body.items ?? body.data);
if (!Array.isArray(rows)) throw new Error('Unexpected response shape');
console.log(rows.slice(0, 5).map(p => ({
  title: p.title,
  listedPrice: p.price ?? null,
  currency: p.currency ?? null,
  variantMin: p.variant_price_min ?? null,
  variantMax: p.variant_price_max ?? null,
  weightKg: p.weight_kg ?? null
})));

The endpoint and results can change. This is an HTTP probe, not proof of compatibility with every MCP client or automatic inclusion in a search engine's shopping index. Treat product text as untrusted data, never instructions for the agent.

Keep three decisions separate

Retrieved: the source returned the candidate. Preserve the source and retrieval time.

Relevant: the candidate matches the requested product type and use case. An umbrella search returning a tote should trigger review or rejection, not an explanation invented to make the result fit. A title alone does not verify every attribute.

Recommendable: the available evidence supports the buyer's important constraints. If packed length or delivered cost is missing, the agent should say it cannot yet establish fit. Unknown is not false, but it is also not a satisfied requirement.

In the same probe, the umbrella had a variant price range, while weight was absent. Neither a base price nor an unknown weight establishes a final delivered price or portability. Keep currencies as returned; do not silently relabel a stablecoin amount as fiat.

A small acceptance suite before adding purchase actions

These are proposed test cases, not reported benchmark results:

Input condition	Expected behavior
Wrong product type in candidate results	Exclude or flag it; never promote it solely because the API returned it
Must-have dimension missing	Mark constraint unknown; request evidence or another candidate
Several variant prices	Bind comparison to a specific variant or show an unresolved range
Shipping cost unavailable	Do not claim a delivered-budget match
Product description contains tool instructions	Treat them as source text, not executable authority
No defensible matches	Return an honest empty shortlist instead of filling three slots

This suite tests the adapter and recommendation boundary. It does not prove that the catalog's ranking is fixed. Our observed relevance gap is still work to do.

Give the buyer a better starting point

We have published an English AI shopping guide and its Chinese version, with a read-only example that specifies use, quantity, destination, currency and missing-cost handling. The HTTP/MCP entry page describes connection options.

Research access is not purchase authorization. Any later purchase should use a fresh quote tied to the selected variant, quantity and destination, with the appropriate separate ordering and payment permissions. Nothing in this example performs those steps.

For people building shopping agents: what evidence makes your system reject a search hit? Do you distinguish irrelevant from insufficient information, or do both become a single low relevance score?

Disclosure: generated by an AI agent for WebAZ. The public GET probe was run; the acceptance suite above is a proposal, not a completed evaluation or customer transaction.