Skip to main content
Glama

logimu-shopping-mcp

by com.logimu.api

shopping

Read-onlyIdempotent

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.

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.
sortNorelevance (default) | price (cheapest first) | rating. USE price when the user asks for the cheapest, rating when they ask for the best-reviewed.relevance
brandNoRestrict to one exact brand. USE WHEN the user names a brand they want ('Anker charger'); prefer this over putting the brand in q.
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
limitNoMax products to return (default 20).
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, 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_stockNoOnly products currently in stock.
max_priceNoMaximum 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_priceNoMinimum price, in the marketplace's local currency. USE WHEN the user sets a floor ('at least £50', 'nothing cheap').

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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