Skip to main content
Glama

logimu-shopping-mcp

by com.logimu.api
OverviewDiscussionsAdmin

serp

Read-onlyIdempotent

LIVE Amazon search-results (SERP) fetch: a real browser navigates Amazon's search page RIGHT NOW and returns the parsed organic result grid plus everything around it. USE WHEN the user wants what Amazon's search page shows THIS MINUTE for a query — current ranking order, who is on page 1, sponsored/ad placements, related searches, refinement filters — or when the curated tools found nothing and the user wants Amazon itself checked. DON'T USE for ordinary product discovery (shopping is <100ms and curated), for filtered datasets (search), or for one known ASIN (product). RETURNS search_results (position, asin, title, link, image, rating, ratings_total, price, list_price, recent_sales badge, sponsored, is_prime), search_information (Amazon's OWN result-count estimate — 'over 20,000' is an estimate, not a count), pagination, related_searches, refinements (round-trip: pass a refinements[*].value back in), ad_blocks / video_blocks (sponsored placements; their links are Amazon ad-redirectors, NOT clean product URLs) and brand_stores (organic store headers only — legitimately empty on sponsored-heavy pages). HONESTY: results per page is Amazon's choice (16-48, varies); sponsored is usually false because Amazon puts paid placements in separate carousels; is_prime false means 'no icon rendered', not 'not Prime'; recent_sales is the verbatim badge string in the page's own language; spelling_correction reports Amazon's autocorrect, it cannot disable it. LATENCY is SECONDS — typically ~8-13s, up to ~90s when the retry ladder runs; tell the user it is a live fetch. Every call is live: there is no cached SERP and no mode parameter. MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br, walmart (live walmart.com search: 2 credits per results page, at most 3 pages a call, location names the store it was priced for; category_id and refinements are Amazon-only). COST API key required (the free no-signup lane cannot run live fetches). 1 credit per page ACTUALLY fetched — max_page=3 can stop at 2 when Amazon runs out; blocked fetches (502) and empty result sets are never billed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesThe search query, exactly as a shopper would type it into Amazon's search box. Query in the marketplace's own language.
pageNoStart page (1-10).
countryNoAmazon marketplace to search, or walmart (a live walmart.com search).us
sort_byNoAmazon's own sort orders; default is Amazon's Featured.
max_pageNoAuto-paginate page..max_page and concatenate (positions stay continuous across pages). Max 10 pages per request; billed per page actually fetched.
category_idNoAmazon browse-node id to scope the search (becomes &node=).
refinementsNoAmazon rh= refinement value. Round-trips: feed back any refinements[*].value from a previous serp response.
exclude_sponsoredNoDrop inline sponsored results. Often a no-op — Amazon usually keeps paid placements in separate carousels outside the organic grid.
number_of_resultsNoTruncate the returned result list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"Amazon marketplace to search. No Walmart — live SERP is Amazon-only."New value: +"Amazon marketplace to search, or walmart (a live walmart.com search)."
    • changedInput schema / properties / country / enum
      Previous value: -[
-  "us",
-  "uk",
-  "de",
-  "ca",
-  "au",
-  "fr",
-  "it",
-  "es",
-  "jp",
-  "mx",
-  "br"
-]New value: +[
+  "us",
+  "uk",
+  "de",
+  "ca",
+  "au",
+  "fr",
+  "it",
+  "es",
+  "jp",
+  "mx",
+  "br",
+  "walmart"
+]
  2. Added
  3. Removed
  4. Added
  5. Removed
  6. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds substantial context beyond them: ~8-13s typical latency up to ~90s with retries, live-only with no caching or mode parameter, API-key requirement, and per-page credit billing with the rule that blocked (502) and empty fetches are never billed. It also discloses result-field caveats (sponsored usually false, is_prime false means no icon, estimates vs counts).

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?

Front-loads the core purpose and is organized with clear USE/DON'T USE/RETURNS/HONESTY/LATENCY/COST headers, and nearly every sentence carries operational information. It is dense and lengthy, but the length is justified by the behavioral, cost and return-shape disclosures rather than padding.

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 carries the return burden and does so fully by enumerating search_results field-by-field plus search_information, pagination, related_searches, refinements, ad_blocks/video_blocks and brand_stores, including their caveats. For a 9-parameter, live-fetch tool this is complete enough to invoke and interpret correctly.

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%, yet the description still adds meaning the schema lacks: walmart caps at 3 pages per call at 2 credits per page, category_id and refinements are Amazon-only, refinements round-trips a prior response's refinements[*].value, and number_of_results truncates the returned list. This is genuinely additive rather than a restatement.

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?

States a specific verb+resource ('LIVE Amazon search-results (SERP) fetch') and immediately distinguishes the tool from siblings by naming shopping, search and product as alternatives for other jobs. An agent can tell it apart from the curated tools without opening a schema.

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?

Contains explicit USE WHEN conditions (current ranking order, page-1 occupants, sponsored placements, refinements, or when curated tools found nothing) and explicit DON'T USE conditions naming the exact sibling for each alternative job (shopping, search, product). Nothing is left to 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 toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources