Skip to main content
Glama

Logimu

by com.logimu
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 (no Walmart). 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. No Walmart — live SERP is Amazon-only.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. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond annotations with latency expectations, Amazon's own quirks (sponsored usually false, is_prime semantics, estimates vs counts, ad-redirector links), marketplace list, API key requirement, and billing rules. This is rich context structured fields cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and usage well, but the RETURNS/HONESTY blocks are dense run-on sentences that hurt scanability despite every claim being substantive.

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?

Complete for a live-fetch tool: covers when to use, latency, cost, marketplace support, return shape, and Amazon-specific caveats. An agent can call it correctly without further context.

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% so baseline is 3; description adds genuine meaning by clarifying round-trip refinements, that sponsored exclusion is often a no-op, and that max_page can stop early when Amazon runs out.

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 and resource ('LIVE Amazon search-results (SERP) fetch') and distinguishes from siblings by naming shopping, search, and product as different tools with different jobs.

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?

Explicit USE WHEN conditions (current ranking order, sponsored placements, fallback when curated tools found nothing) and explicit DON'T USE for three named alternatives with reasons.

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

All Logimu 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