logimu-shopping-mcp

search

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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.

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All logimu-shopping-mcp tools Inspect

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

Need Help?