Skip to main content
Glama
ncosic

logimu-shopping-mcp

shopping

Read-only

Takes a shopping keyword and returns a ranked shortlist of products grouped by category or price tier, using real marketplace data. Ideal for 'best X' or 'find me Y under $Z' queries.

Instructions

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: '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 the real current prices, availability, demand and price history whenever a purchase is being considered. 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, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesWhat 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.
groupNoHow 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
detailNoAttach 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.
countryNoMarketplace 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.us
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations set `readOnlyHint: true`, but the description adds substantial behavioral context: ranking uses observed marketplace signals with no affiliate or sponsored bias; zero results means genuine no match, never a best-effort guess; data is revealed-preference; and details about result grouping, freshness, and citability. This goes well beyond what annotations provide.

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 lengthy but well-structured with clear sections (USE WHEN, DON'T USE, RETURNS, HANDOFF, EXAMPLE, etc.). Every sentence serves a purpose, but some parts (e.g., detailed market-specific language rules) could be condensed. Overall, it balances completeness with organization.

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?

Given the tool's complexity (4 parameters, no output schema), the description is exceptionally complete. It covers behavior, error handling (zero results), handoff patterns, cost details, and language-specific guidance. It leaves no major gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds extensive parameter guidance: query style (literal keywords, not semantic), language rules (e.g., umlauts, brand+noun pairing), marketplace selection, and handling of zero results. It explains the `group` parameter's modes and the `detail` parameter's cost implications, significantly enriching the schema.

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 clearly states the tool's purpose: 'Curated product discovery: a shopping keyword in, a ranked and grouped shortlist out'. It specifies the verb (search/discover), resource (products), and distinguishes from siblings by explicitly stating when to use `product` (when ASIN is known) and `search` (when filtered dataset is wanted).

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?

The description provides explicit usage guidelines: 'USE WHEN the user asks 'best X', 'find me a Y under $Z', 'what should I buy', or wants a shortlist' and '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)'. It also includes handoff instructions to the `product` tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ncosic/logimu-shopping-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server