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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.9/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: product for a known item's history, search for filtered structured lists, and shopping for curated discovery. The descriptions explicitly cross-reference when to use each and warn against misuse, eliminating ambiguity.
All tool names are single lowercase words, which is consistent in style, but they mix a resource (product) with actions (search, shopping), lacking a uniform verb_noun pattern. This is a minor deviation from the ideal but remains clear and predictable.
With 3 tools, the server is well-scoped for its purpose: discovery, filtering, and deep-dive history. Each tool earns its place, and the count falls comfortably within the typical 3-15 range.
The tool surface covers the full shopping workflow: discovering products (shopping), querying with filters (search), and retrieving detailed history for a specific product (product). There are no obvious dead ends, and the descriptions handle edge cases like non-ranked items and marketplace variances.
productAFull 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 a free API key — 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 a free API key (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?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint false), the description discloses critical behavioral traits: cost/credits, cache vs live mode restrictions, marketplace availability, Walmart's numeric ID requirement, miss/hint behavior, content_observed_at null semantics, BSR fallback for ~17% of catalog, and data_source attribution. This is far more than the annotations alone provide.
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 long and dense, but it is organized into clear sections (purpose, when to use, when not, returns, caveats, cost). Every sentence carries substantive detail for a complex tool; the length is justified, though some phrases are slightly repetitive and could be tightened.
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 full responsibility for explaining return values, and it does so comprehensively: current snapshot, history, change events, offer table, brand stats, content block, BSR fallback, data_source, and cost behavior. It also covers failure modes and marketplace specifics, making the tool fully usable without external documentation.
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 baseline is 3. The description adds value beyond the schema by explaining how to supply identifiers (ASIN, product link, product_id from shopping/search), when barcodes are used, and how mode=live behaves for keyless callers. It does not fully document every parameter, but it meaningfully augments the schema.
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 'Full dossier for ONE known product' and immediately distinguishes it from siblings by stating it is the ONLY tool that returns history. It clearly names the resource (a specific product) and the operation (retrieve current snapshot plus observed history), leaving no ambiguity about what it does.
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 provides explicit USE WHEN conditions with concrete examples of user queries, and explicit DON'T USE instructions that point to alternatives (shopping for keyword discovery, search for filtered lists). It also names the sibling tools that should be used instead, making the decision boundary crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAFiltered query over the tracked-product warehouse (17M+ 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?
The description adds substantial behavioral context beyond the readOnlyHint annotation: coverage is limited to the tracked BSR universe, not the entire catalog; every returned row is observed marketplace data; cost/free-lane limits are disclosed (1 of 30 daily queries, 25-row cap, no billing for empty sets); and q is literal, not semantic. No contradiction with 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 long but every sentence carries information. It is front-loaded with purpose and usage, uses logical separators (DON'T USE, RETURNS, Requires, COVERAGE, COST), and avoids fluff. The length is justified by the tool's complexity.
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?
For a 19-parameter tool with no output schema, the description is exceptionally complete: it covers return fields, ordering, anchors, marketplace defaults, coverage limitations, cost model, empty-result behavior, and downstream use (cite product_id, pass to product tool). No critical context 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%, so baseline is 3, but the main description adds meaning beyond the schema: it explains the anchor requirement, that seller is refinement-only, that the free lane caps limit at 25, and the dual role of category as anchor or refinement. Some param clarifications exist in the schema descriptions themselves, so a 4 reflects solid added value without perfect compensation.
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 and resource: 'Filtered query over the tracked-product warehouse.' It clearly distinguishes from siblings by explicitly saying 'DON'T USE for best X' buying advice (use shopping) or for a single known product (use product). The scope is unambiguous.
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?
Extremely explicit when-to-use guidance with concrete examples ('well-rated dehumidifiers under $150...'). It also gives when-not-to-use and names alternative tools (shopping, product). It states the anchor requirement (pass q, brand, or category) and marks some params as refinement-only, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shoppingACurated 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?
The description goes well beyond the annotations by disclosing no affiliate/sponsored bias, the meaning of zero results, honesty signals (interpreted_as, match_quality), literal keyword matching quirks (screen sizes selecting accessories), and the billing/cost model. No contradiction with 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?
Although long, every sentence carries a distinct rule or example. It is front-loaded with the core purpose and organized with clearly visible sections (USE WHEN, DON'T USE, HANDOFF, EXAMPLE, QUERY STYLE, LANGUAGE, MARKETPLACES, COST). No filler or redundancy.
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?
Despite having no output schema, the description fully specifies the return structure: ranked products grouped by category or price tier, each with product_id, product_url, title, price, rating, review count, stock, observed_at, brand facets, plus data_source, interpreted_as, and match_quality. It covers edge cases like zero results, language quirks, and marketplace coverage, making it complete for the tool's complexity.
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?
Even with 100% schema description coverage, the main description adds substantial new meaning: query language rules (German compounds, umlauts), brand collision examples, cost implications of detail=true, marketplace selection based on user locale, and extra guidance for sort ('USE price when the user asks for the cheapest, rating when they ask for the best-reviewed'). This lifts the value beyond the structured schema.
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 and resource: 'Curated product discovery: a shopping keyword in, a ranked and grouped shortlist out, in under ~100ms.' It clearly differentiates from siblings by stating '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).'
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?
Explicit USE WHEN scenarios are provided ('best X', 'find me a Y under $Z', 'what should I buy'), along with definite DON'T USE and HANDOFF instructions to the product tool. It also specifies when to set detail=true and when to pass product_id to product, leaving no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
