Skip to main content
Glama

logimu-shopping-mcp

by com.logimu.api

product

Read-onlyIdempotent

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asinYes10-character Amazon ASIN, or a numeric Walmart item ID when country=walmart. Provide either asin or gtin.
gtinNoGTIN / 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.
modeNocache = 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
countryNoMarketplace 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_historyNoAttach 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_daysNoHow old a cached observation may be before mode=auto triggers a live scrape.
offer_historyNoAttach 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.

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All logimu-shopping-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources