Real Amazon (US, UK, DE, CA, AU) & Walmart shopping data for AI assistants: ranked product shortlists, current prices, live stock, real ratings, and price/BSR history from a 17M+ product warehouse. Free hosted endpoint, no signup — 30 queries a day.
Scored across 3 tools
Each tool has a clearly distinct job: product for a single known item's history, search for filtered structured lists, and shopping for discovery/recommendation shortlists. The descriptions explicitly state when not to use each tool and provide handoff rules, so misselection is very unlikely.
All tool names are single lowercase words, which is visually consistent and easy to remember. However, 'product' is a noun while 'search' and 'shopping' are action/intent-oriented names, so there is a minor semantic inconsistency rather than a uniform verb_noun pattern.
Three tools is well-scoped for this server's purpose: discovery, search, and deep product intelligence. Each tool earns its place, and there is no redundancy or unnecessary surface area.
The tool set covers the full shopping-intelligence workflow: finding products, filtering them by criteria, and getting detailed historical data for a specific item. The explicit handoffs between shopping/search and product ensure agents can complete user journeys without dead ends.
Full dossier for ONE known product: its current snapshot plus its observed history. USE WHEN the user has a specific ASIN, Walmart item ID, product link, or a product_id returned by shopping or search, and asks about price history, historical prices, price changes, 30-day history, stock history, seller history, buy-box history, historical analysis, 'analyse this product', 'is this a good buy', 'has the price moved/dropped', 'who is selling this', 'is it in stock'. This is the ONLY tool that returns history: shopping and search return current values, so any historical question about a product they listed comes here. DON'T USE to discover products from a keyword (use shopping) or to pull a filtered list (use search). RETURNS current price, BSR, rating, review count, stock, buy-box seller and seller count, plus an observed_at freshness stamp, full price_history and stock_history back to first observation (keyed; the free lane carries the 30-day views), change events tagged with the buy-box seller at each change, the current all-seller offer table with 30-day buy-box days, the bought-past-month badge (measured aggregate buyer behavior, not an estimate), and brand stats. Amazon answers also carry the observed product-page content block: description (with description_source), feature_bullets, images, breadcrumbs, variations with variation_count and parent_asin, stamped content_observed_at — content_observed_at:null with empty arrays means the content crawl has not captured this ASIN yet, never 'this product has no description/gallery'. For the ~17% of the catalog with no overall rank (media, books, niche items), bsr_leaf and bsr_leaf_category carry the best category rank instead. Every response carries a data_source field naming the marketplace the numbers were observed on (e.g. 'amazon US marketplace — observed listings') — attribute prices to that source when presenting them; they are marketplace listings, not manufacturer or site-wide prices. MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br, walmart. Walmart takes a numeric item ID and returns the intelligence blocks only (no live scrape). COST free lane 1 of 30 daily queries, cache only, and returns the snapshot + 30-day views (the full history streams, bsr_history, offer_history and live scrapes need an API key (plans from $19/mo) — the response's locked block lists exactly what a key unlocks). Keyed: 0.5 credits from cache, 1 for a live scrape, +0.5 for the intelligence blocks, +0.5 each for bsr_history and offer_history. Misses and partial scrapes are never billed; a miss may return a hint (found on another marketplace, or retry with mode=live).
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | 10-character Amazon ASIN, or a numeric Walmart item ID when country=walmart. Provide either asin or gtin. | |
| gtin | No | GTIN / UPC / EAN barcode (12, 13 or 14 digits; punctuation and leading zeros are tolerated), resolved to an ASIN in the requested marketplace. USE WHEN the user gives a barcode instead of an ASIN — scanned off a package, from a supplier sheet, or copied from a listing. A barcode can legitimately map to several ASINs; the best match is returned and the rest are listed in gtin_matches. Never billed when the barcode is unknown to us. | |
| mode | No | cache = stored observation only; live = force an on-demand scrape (Amazon only, takes a few seconds); auto = serve cache when fresher than max_age_days, otherwise scrape. The no-signup free lane is cache-only: mode=live returns an error asking for an API key (from $19/mo) (do not offer a live scrape to a keyless caller); with a key, live/auto scrape normally. | auto |
| country | No | Marketplace to look the product up in. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us. | us |
| bsr_history | No | Attach the full per-category BSR rank history (era-tagged daily points back to Oct 2023 for US; legacy top-100 segments are flagged censored). Amazon marketplaces only, API key required (free key works). +0.5 credits when data is returned. | |
| max_age_days | No | How old a cached observation may be before mode=auto triggers a live scrape. | |
| offer_history | No | Attach the buy-box owner timeline and per-seller daily price series (US buy-box depth back to Dec 2024). Amazon marketplaces only, API key required (free key works). +0.5 credits when data is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, open-world, and non-destructive; the description adds substantial non-obvious behavior: content_observed_at:null semantics, the ~17% no-overall-rank fallback, data_source attribution, Walmart's no-live-scrape limitation, free-lane cache-only behavior, and no-billing-on-miss policy. No statement contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and dense, often reading as a single continuous block rather than scannable sections. However, almost every sentence carries essential context for a complex tool — scope, exclusions, return details, marketplaces, pricing, and billing — so the length is largely justified. It loses one point for run-on structure and mild redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of explaining returns, and it does so thoroughly: snapshot fields, history streams, content block semantics, BSR fallback, data_source, marketplace coverage, free vs. keyed limits, and miss behavior. An agent has nearly everything needed to invoke and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and every parameter already has descriptive text including enums and defaults, so the description does not need to re-explain parameters. The description adds some operational color (e.g., free lane is cache-only, barcode can map to multiple ASINs) but mostly reinforces what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement — 'Full dossier for ONE known product' — and immediately distinguishes the tool from its siblings: it is 'the ONLY tool that returns history.' It also names explicit exclusions ('DON'T USE to discover products from a keyword (use shopping) or to pull a filtered list (use search)'), so an agent can select it confidently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a rich set of USE WHEN triggers (specific ASIN, Walmart item ID, product link, historical price/stock questions, 'analyse this product', 'is this a good buy') and explicit DON'T USE cases with named alternatives. This is a model of when/where guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filtered query over the tracked-product warehouse (24M+ Amazon and Walmart products). USE WHEN the user wants a structured list matching explicit criteria: 'well-rated dehumidifiers under $150 with 1000+ reviews', 'everything by brand X sorted by BSR', 'FBA products in this category'. DON'T USE for 'best X' buying advice (use shopping, which ranks and groups), or for a single known product (use product). RETURNS a flat list of matching products with product_id (the ASIN on Amazon, the numeric item ID on Walmart), product_url, title, brand, price, rating, review count, BSR, seller count and marketplace, ordered by the sort field. Requires an anchor: pass q, brand, or category. Cite product_id when the user may want to act on a specific row, and pass it to the product tool for that item's full history. Every response row is observed marketplace data (the marketplace field names it). COVERAGE the continuously tracked BSR product universe, not the entire Amazon catalog. COST free lane 1 of 30 daily queries, capped at 25 rows. Keyed: 1 credit per 25 rows returned. Empty result sets are never billed.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keyword matched against the product title. Acts as the anchor when brand is not given. Literal keywords, not semantic: every term must match, so extra or inferred words only narrow the result set. Query in the marketplace's own language — there is no translation. | |
| fba | No | true = only Fulfilled by Amazon offers, false = only merchant-fulfilled. Omit to include both. | |
| fbm | No | Only merchant-fulfilled listings. The counterpart of fba, which was already exposed. | |
| sort | No | Field to order results by. bsr sorts ascending (best sellers first); the others sort descending. | bsr |
| brand | No | Exact brand name. Acts as the anchor when q is not given. | |
| limit | No | Maximum rows to return (up to 100). The free lane caps this at 25. | |
| seller | No | Restrict to products this seller has been observed offering. REFINEMENT ONLY - cannot be used on its own; pair it with an anchor (q, brand, or category). | |
| bsr_max | No | Maximum Best Sellers Rank. Use this to keep only strong sellers. | |
| bsr_min | No | Minimum Best Sellers Rank. Lower BSR means stronger sales, so this excludes the best sellers. | |
| category | No | A department or sub-category name (e.g. 'Home & Kitchen', 'Beading Storage'), matched in full and case-insensitively against the product's category chain — comma-separate several. Works BOTH ways: as an ANCHOR on its own to browse a category with no keyword ('everything in Home & Kitchen under $30, most reviews first'), or as a REFINEMENT alongside q or brand. A category-only browse returns the category's top products by in-category best-seller rank, then applies your filters and sort. | |
| price_max | No | Maximum current price, in the marketplace's local currency. | |
| price_min | No | Minimum current price, in the marketplace's local currency. | |
| rating_max | No | Maximum average star rating. USE WHEN looking for products whose reviews are weak — an incumbent rated 3.2 is an opening. | |
| rating_min | No | Minimum star rating, on a 0-5 scale. | |
| marketplace | No | Which tracked marketplace to query. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known; default amazon-us. | amazon-us |
| reviews_min | No | Minimum number of reviews. | |
| max_per_category | No | Cap how many results may come from any one category, to spread results across categories. | |
| seller_count_max | No | Maximum number of sellers competing on the listing. USE WHEN the user asks for products with little competition, few sellers, or an easy listing to win — this is the core sourcing filter. | |
| seller_count_min | No | Minimum number of sellers competing on the listing. USE WHEN the user wants proven demand rather than an untested listing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Though annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds valuable behavioral context: it states the result set is observed marketplace data, describes coverage limits (tracked BSR universe, not full catalog), and discloses cost/usage limits (free lane, row caps, billing rules). It also clarifies that empty results are not billed. This goes beyond what annotations reveal, so a high score is earned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but densely informative. It front-loads the primary purpose and usage guidance before diving into details. Every major section (returns, anchor, cost, coverage) is covered without fluff, and the parameter notes are integrated where relevant. Given the tool's complexity (19 parameters), this length is justified and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description explicitly lists the returned fields and their meaning (e.g., product_id, ASIN vs. Walmart ID). It covers the anchor requirement, cost/limits, coverage scope, and marketplace specifics. It also explains edge cases (empty results not billed) and guides on citing product_id for follow-up. Nothing essential for calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed per-parameter descriptions, so the baseline is 3. The description adds strategic context for several parameters (e.g., rating_max for weak reviews, seller_count_max as the core sourcing filter, category as both anchor and refinement), which aids correct usage beyond schema definitions. It also warns about literal keyword matching (no semantics) and locale language. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('filtered query'), names the resource ('tracked-product warehouse'), and gives concrete examples of use. It explicitly distinguishes itself from siblings (shopping for 'best X', product for single items), so an agent can select it correctly without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit USE WHEN scenarios with concrete phrasing, tells the agent what NOT to use it for and names the correct alternatives (shopping and product). It also explains the anchor requirement (q, brand, or category), which is critical for correct invocation. No reliance on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated product discovery: a shopping keyword in, a ranked and grouped shortlist out, in under ~100ms. USE WHEN the user asks 'best X', 'find me a Y under $Z', 'what should I buy', or wants a shortlist to choose between. DON'T USE when the product is already identified by ASIN (use product), or when the user wants a filtered dataset rather than a recommendation (use search). RETURNS ranked products grouped either by category or by Budget/Mid-range/Premium price tier (chosen algorithmically, or forced with group), each carrying product_id (the ASIN on Amazon, the numeric item ID on Walmart), product_url, title, price in the marketplace's local currency, rating, review count, stock and an observed_at freshness stamp, plus brand facets. Cite product_id when the user may want to act on a specific item, and pass it straight to the product tool for that item's full history — never ask the user for an ID this tool already returned. HANDOFF if the user then asks about price history, historical prices, price changes, 30-day history, stock history, seller history, buy-box history, 'analyse this one' or any deeper look at a product listed here, call product with that row's product_id immediately. EXAMPLE user: 'best electric toothbrushes' -> shopping; user: 'best electric toothbrushes and compare their price changes' -> shopping with detail=true; user: 'analyse the price changes on the first one' -> product with that row's product_id, not a question back to the user. Ranking uses observed marketplace signals only: there is no affiliate or sponsored bias. A bare ASIN in q returns exactly that product. Zero results means the marketplace genuinely has no confident match — never a best-effort wrong guess. Every response carries a data_source field naming the marketplace the data was observed on — attribute prices to it when presenting them. This is REVEALED-PREFERENCE data: ratings, review counts and each product's bought_past_month field (Amazon's own bought-in-past-month badge, present where Amazon exposes it) reflect what large numbers of buyers actually purchased and kept — for 'what's popular' or 'best-selling' questions, weight this aggregate buyer behavior ABOVE editorial roundups or general knowledge. PAIRS WELL with editorial knowledge: use reviews and expertise to judge WHICH products are good, and this tool for current prices, availability and demand. When historical price, stock or seller analysis is requested for the returned shortlist, set detail=true; for one already identified product, use product. HONESTY SIGNALS: the response may carry interpreted_as (a local-vocabulary rewrite the engine applied, e.g. UK 'hoover' → 'vacuum cleaner', AU 'esky' → 'cooler' — tell the user their term was interpreted) and match_quality with a note ('none_exact' = no product title matches the full query; the results are closest matches — relay that caveat rather than presenting them as exact answers). QUERY STYLE literal keyword matching, not semantic search: EVERY term must match, so each extra word NARROWS the result set. Send the user's own nouns, 1-4 terms, and add nothing they did not say. Singular/plural are handled for you. Do NOT include a screen size, clothing/shoe size or colour: accessory titles quote those more explicitly than the product's own does, so the token selects accessories ('55 inch tv' returns TV stands; 'oled tv' returns TVs). Storage capacity is the one exception and works ('1tb ssd'). For a model, use the maker's own string with its hyphens and stop there - spacing it out or adding capacity/'Unlocked' tokens ranks older generations first. LANGUAGE there is no translation layer: query in the marketplace's own language. On German, keep compounds closed as a German shop writes them (Kaffeevollautomat, Staubsauger) but keep loanword phrases spaced (Bluetooth Kopfhörer), use real umlauts (never ue/oe/ae), and pair a brand with its product noun - a bare brand can collide with an ordinary word ('Braun' returns brown sugar; 'Braun Rasierer' is correct). ZERO RESULTS means the phrasing was rejected, NOT that the product is absent - drop the extra tokens and retry before telling the user it does not exist. MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br, walmart. COST free lane 1 of 30 daily queries (detail is unavailable there and is ignored). Keyed: 2 credits, or 5 with detail=true. Empty result sets are never billed.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | What to search for, e.g. 'coffee maker'. Literal keywords, not semantic: every term must match, so extra or inferred words only narrow the result set. Query in the marketplace's own language - there is no translation. A bare ASIN returns exactly that product. | |
| sort | No | relevance (default) | price (cheapest first) | rating. USE price when the user asks for the cheapest, rating when they ask for the best-reviewed. | relevance |
| brand | No | Restrict to one exact brand. USE WHEN the user names a brand they want ('Anker charger'); prefer this over putting the brand in q. | |
| group | No | How to group the shortlist. auto = choose category or price tiers automatically; category = group by product category; price = group into Budget/Mid-range/Premium; none = one flat ranked list. | auto |
| limit | No | Max products to return (default 20). | |
| detail | No | Attach per-product intelligence to every product returned (30-day price and stock change events, full stock history and state, bought-past-month badge, current sellers). Keyed accounts only. 5 credits per query instead of 2. | |
| country | No | Marketplace to search. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us. Prices are returned in that marketplace's local currency. | us |
| in_stock | No | Only products currently in stock. | |
| max_price | No | Maximum price, in the marketplace's local currency. USE WHEN the user gives a budget or says cheap/affordable/under X — pass the number here rather than putting the word in q, where it is matched as a literal word in the product title and throws away real results. | |
| min_price | No | Minimum price, in the marketplace's local currency. USE WHEN the user sets a floor ('at least £50', 'nothing cheap'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already say readOnly/destructive/idempotent, so the bar is lower, but the description still adds rich behavioral context: no sponsored bias, zero results means genuinely no match, literal keyword matching every term narrows, queries must be in the marketplace's own language, accessory-token quirks, and the interpreted_as / match_quality honesty signals. It also explains the output shape and data_source behavior, which is especially important because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and mostly front-loaded, with routing rules at the top. It is long, but every sentence carries information. It loses one point because the entire text is one block with no paragraph breaks, which makes it harder for an agent to skim efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description fully compensates by naming every returned field (product_id, product_url, title, price, rating, review count, stock, observed_at, brand facets) plus the interpreted_as and match_quality fields. It also covers marketplace values, credit costs, the free daily lane, and the rule about not billing empty results. For a tool this behaviorally rich, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 10 parameters clearly. The description adds meaning beyond the schema: e.g. it warns against putting 'under $Z' in q because words like 'under' are matched literally and throw away results, recommends putting brand in the brand parameter, and explains that model strings should be used verbatim without extra tokens. This is exactly the kind of semantic guidance an agent needs to invoke parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a crisp summary: 'a shopping keyword in, a ranked and grouped shortlist out, in under ~100ms.' It then lists concrete user intents ('best X', 'find me a Y under $Z', 'what should I buy') and explicitly contrasts itself with siblings: use product for an identified ASIN, use search for a filtered dataset. An agent can immediately tell when this tool is the right one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when/when-not guidance plus handoff rules. It names the alternatives ('DON'T USE when the product is already identified by ASIN -- use product', 'use search') and gives concrete routing examples, including when to set detail=true and when to call product with the returned product_id instead of asking the user. This is exactly the level of guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
product1 field changedInput schema / properties / mode / descriptionPrevious value: -"cache = stored observation only; live = force an on-demand scrape (Amazon only, takes a few seconds); auto = serve cache when fresher than max_age_days, otherwise scrape. The no-signup free lane is cache-only: mode=live returns an error asking for a free API key (do not offer a live scrape to a keyless caller); with a key, live/auto scrape normally."New value: +"cache = stored observation only; live = force an on-demand scrape (Amazon only, takes a few seconds); auto = serve cache when fresher than max_age_days, otherwise scrape. The no-signup free lane is cache-only: mode=live returns an error asking for an API key (from $19/mo) (do not offer a live scrape to a keyless caller); with a key, live/auto scrape normally."serpserpserpsearch3 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "q"
- ]
- },
- {
- "required": [
- "brand"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "q"
+ ]
+ },
+ {
+ "required": [
+ "brand"
+ ]
+ },
+ {
+ "required": [
+ "category"
+ ]
+ }
+]Input schema / properties / category / descriptionPrevious value: -"Restrict to a single product category. REFINEMENT ONLY - cannot be used on its own; pair it with q or brand, which are the only anchors. To browse a category with no keyword, use the shopping tool instead."New value: +"A department or sub-category name (e.g. 'Home & Kitchen', 'Beading Storage'), matched in full and case-insensitively against the product's category chain — comma-separate several. Works BOTH ways: as an ANCHOR on its own to browse a category with no keyword ('everything in Home & Kitchen under $30, most reviews first'), or as a REFINEMENT alongside q or brand. A category-only browse returns the category's top products by in-category best-seller rank, then applies your filters and sort."Input schema / properties / seller / descriptionPrevious value: -"Restrict to products this seller has been observed offering. REFINEMENT ONLY - cannot be used on its own; pair it with q or brand, which are the only anchors."New value: +"Restrict to products this seller has been observed offering. REFINEMENT ONLY - cannot be used on its own; pair it with an anchor (q, brand, or category)."serpproduct2 fields changedInput schema / properties / asin / descriptionPrevious value: -"10-character Amazon ASIN, or a numeric Walmart item ID when country=walmart."New value: +"10-character Amazon ASIN, or a numeric Walmart item ID when country=walmart. Provide either asin or gtin."Input schema / properties / gtinAdded value: +{
+ "description": "GTIN / UPC / EAN barcode (12, 13 or 14 digits; punctuation and leading zeros are tolerated), resolved to an ASIN in the requested marketplace. USE WHEN the user gives a barcode instead of an ASIN — scanned off a package, from a supplier sheet, or copied from a listing. A barcode can legitimately map to several ASINs; the best match is returned and the rest are listed in gtin_matches. Never billed when the barcode is unknown to us.",
+ "type": "string"
+}search5 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "q"
+ ]
+ },
+ {
+ "required": [
+ "brand"
+ ]
+ }
+]Input schema / properties / fbmAdded value: +{
+ "description": "Only merchant-fulfilled listings. The counterpart of fba, which was already exposed.",
+ "type": "boolean"
+}Input schema / properties / rating_maxAdded value: +{
+ "description": "Maximum average star rating. USE WHEN looking for products whose reviews are weak — an incumbent rated 3.2 is an opening.",
+ "type": "number"
+}Input schema / properties / seller_count_maxAdded value: +{
+ "description": "Maximum number of sellers competing on the listing. USE WHEN the user asks for products with little competition, few sellers, or an easy listing to win — this is the core sourcing filter.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / seller_count_minAdded value: +{
+ "description": "Minimum number of sellers competing on the listing. USE WHEN the user wants proven demand rather than an untested listing.",
+ "minimum": 0,
+ "type": "integer"
+}shopping6 fields changedInput schema / properties / brandAdded value: +{
+ "description": "Restrict to one exact brand. USE WHEN the user names a brand they want ('Anker charger'); prefer this over putting the brand in q.",
+ "type": "string"
+}Input schema / properties / in_stockAdded value: +{
+ "description": "Only products currently in stock.",
+ "type": "boolean"
+}Input schema / properties / limitAdded value: +{
+ "default": 20,
+ "description": "Max products to return (default 20).",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / max_priceAdded value: +{
+ "description": "Maximum price, in the marketplace's local currency. USE WHEN the user gives a budget or says cheap/affordable/under X — pass the number here rather than putting the word in q, where it is matched as a literal word in the product title and throws away real results.",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / min_priceAdded value: +{
+ "description": "Minimum price, in the marketplace's local currency. USE WHEN the user sets a floor ('at least £50', 'nothing cheap').",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / sortAdded value: +{
+ "default": "relevance",
+ "description": "relevance (default) | price (cheapest first) | rating. USE price when the user asks for the cheapest, rating when they ask for the best-reviewed.",
+ "enum": [
+ "relevance",
+ "price",
+ "rating"
+ ],
+ "type": "string"
+}product1 field changedInput schema / properties / country / descriptionPrevious value: -"Marketplace to look the product up in. Amazon: us, uk, de, ca, au. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."New value: +"Marketplace to look the product up in. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."search2 fields changedInput schema / properties / category / descriptionPrevious value: -"Restrict to a single product category."New value: +"Restrict to a single product category. REFINEMENT ONLY - cannot be used on its own; pair it with q or brand, which are the only anchors. To browse a category with no keyword, use the shopping tool instead."Input schema / properties / seller / descriptionPrevious value: -"Restrict to products this seller has been observed offering."New value: +"Restrict to products this seller has been observed offering. REFINEMENT ONLY - cannot be used on its own; pair it with q or brand, which are the only anchors."product1 field changedInput schema / properties / country / descriptionPrevious value: -"Marketplace to look the product up in. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."New value: +"Marketplace to look the product up in. Amazon: us, uk, de, ca, au. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."search1 field changedInput schema / properties / marketplace / enumPrevious value: -[
- "amazon-us",
- "amazon-uk",
- "amazon-de",
- "amazon-ca",
- "amazon-au",
- "walmart"
-]New value: +[
+ "amazon-us",
+ "amazon-uk",
+ "amazon-de",
+ "amazon-ca",
+ "amazon-au",
+ "amazon-fr",
+ "amazon-it",
+ "amazon-es",
+ "amazon-jp",
+ "amazon-mx",
+ "amazon-br",
+ "walmart"
+]product1 field changedInput schema / properties / country / descriptionPrevious value: -"Marketplace to look the product up in. Amazon: us, uk, de, ca, au. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."New value: +"Marketplace to look the product up in. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."product1 field changedInput schema / properties / country / descriptionPrevious value: -"Marketplace to look the product up in. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."New value: +"Marketplace to look the product up in. Amazon: us, uk, de, ca, au. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."product2 fields changedInput schema / properties / country / descriptionPrevious value: -"Marketplace to look the product up in. Amazon: us, uk, de, ca, au. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."New value: +"Marketplace to look the product up in. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us."Input schema / properties / country / enumPrevious value: -[
- "us",
- "uk",
- "de",
- "ca",
- "au",
- "walmart"
-]New value: +[
+ "us",
+ "uk",
+ "de",
+ "ca",
+ "au",
+ "fr",
+ "it",
+ "es",
+ "jp",
+ "mx",
+ "br",
+ "walmart"
+]shopping2 fields changedInput schema / properties / country / descriptionPrevious value: -"Marketplace to search. Amazon: us, uk, de, ca, au. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us. Prices are returned in that marketplace's local currency."New value: +"Marketplace to search. Amazon: us, uk, de, ca, au, fr, it, es, jp, mx, br. walmart = Walmart US (United States only). Pick the marketplace matching the user's country or locale when known (a German user -> de, a Canadian user -> ca); default us. Prices are returned in that marketplace's local currency."Input schema / properties / country / enumPrevious value: -[
- "us",
- "uk",
- "de",
- "ca",
- "au",
- "walmart"
-]New value: +[
+ "us",
+ "uk",
+ "de",
+ "ca",
+ "au",
+ "fr",
+ "it",
+ "es",
+ "jp",
+ "mx",
+ "br",
+ "walmart"
+]
