Skip to main content
Glama

Amazon MCP

Search an Amazon store (prices in PLN)

amazon_search

Search one Amazon store (22 countries; default amazon.pl) via SerpAPI, with every price also in PLN at the official NBP mid rate. Costs one SerpAPI credit per call (a repeat within 5 minutes is cached and free). Refine with sort, page, min_price/max_price (store currency; enforced on the displayed price), brand, category_node, min_rating/min_reviews (applied to the returned page), include_sponsored, and any refinement Amazon offers on that page via rh: the result's filters lists each option's rh (Prime, 4★ & up, New condition, sold by Amazon, deals, features…) — pass them comma-separated. A store printing PLN itself (shipping_location 'PL' on a foreign store) is taken as-is. Use amazon_compare for several stores at once and amazon_product for one ASIN's offers, sellers and specs. Result shape: { source, fetchedAt, query, marketplace: { code, domain, country, currency, language }, search_url, total_results (Amazon's own count, before this page's post-filters), query_displayed?, page, next_page, count, products: [...], filters?: { : [{ name, rh }] }, categories?: [{ name, node }], related_searches?, fx: [{ currency, rate, table, table_no, effective_date, source: 'NBP' }], note? } — the list key is products. Each product: { position, asin, title, brand?, url (https://www./dp/), image?, price (number, in currency), price_text (as displayed), currency (ISO, read from the displayed price), price_pln, old_price?, discount_percent?, rating, reviews, bought_last_month?, prime? (only stores that mark it), sponsored, badges?, delivery?, stock?, coupon?, offers?, more_buying_choices?, variants?: [{ asin, title }], purchase_options? }. price_pln is null when there is no price or no NBP rate (the note says why). A search Amazon answers with nothing is count: 0 plus a note on what to relax — a successful result, not an error.

Input Schema

NameRequiredDescriptionDefault
rhNoAmazon refinements, comma-separated key:value pairs exactly as a previous result's `filters` list them (e.g. 'p_n_condition-type:776949031,p_72:419117031'). Ids are store-specific.
pageNoResult page, 1–20. Default 1.
sortNoAmazon's sort: relevance (default, Amazon's 'Featured'), price_asc, price_desc, rating (avg. customer review), newest, bestsellers. The price sorts are re-applied to the returned page by displayed price (Amazon sorts by its offer prices), with products that show no price listed last.
brandNoOne brand name as Amazon spells it, e.g. 'Sony' (Amazon's brand filter).
limitNoMax products returned (1–60). Default 20.
queryNoWhat you'd type in Amazon's search box, e.g. 'sony wh-1000xm5'. Required unless category_node is set.
languageNoStore language as <language>_<REGION>, e.g. 'en_GB' for English titles on amazon.de. Default: the store's own (de_DE on amazon.de) — each store only offers a few (amazon_marketplaces lists them).
no_cacheNoForce a fresh SerpAPI fetch, bypassing this server's 5-minute result cache. Default false.
max_priceNoHighest price in the store's currency, applied like min_price.
min_priceNoLowest price in the STORE's currency (EUR on amazon.de). Sent to Amazon, then enforced on the displayed price: out-of-range products and products without a price are dropped (the note counts them).
min_ratingNoKeep products rated at least this (0–5), filtered on the returned page.
marketplaceNoAmazon store: its code (pl, de, fr, it, es, nl, be, se, uk, tr, us, ca, mx, br, au, jp, in, cn, sg, ae, sa, eg) or domain (amazon.de, amazon.co.uk…). Default pl.
min_reviewsNoKeep products with at least this many ratings, filtered on the returned page.
delivery_zipNoDelivery postal code within shipping_location's country (or the store's), e.g. '00-001'.
category_nodeNoAmazon browse-node id (digits) to search within — from a result's `categories`, or node=… in an Amazon category URL. Ids differ per store. Without a query this browses the category.
convert_to_plnNoAdd price_pln at the NBP mid rate. Default true.
include_filtersNoReturn the page's refinement `filters` (name + rh per option). Default true.
include_sponsoredNoKeep sponsored slots (marked sponsored: true). Default false — ads repeat and distort ranking.
shipping_locationNoDeliver-to country as an ISO code, e.g. 'PL': a foreign store then lists only items it delivers there, adds delivery cost to `delivery`, and usually prints prices already converted to PLN by Amazon (VAT of the destination). 'local' (or omitted) = the store's own country.
exclude_autocorrectedNoDrop results Amazon adds from an auto-corrected spelling of the query. Default false.

Output Schema

NameRequiredDescriptionDefault
fxYes
noteNo
pageNo
countYes
queryYes
sourceYes
filtersNo
productsYes
fetchedAtYes
next_pageNo
categoriesNo
search_urlNo
marketplaceYes
total_resultsNo
related_searchesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses SerpAPI credit cost, 5-minute caching, post-filtering behavior, price_pln null semantics, sponsored defaults, and that empty searches return count 0 with a note rather than an error.

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?

The core purpose, cost, alternatives, and refinement behavior are front-loaded, but the description is very long and includes an extensive result-shape block even though an output schema exists. That return-shape detail is largely redundant and hurts conciseness.

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?

For a complex 20-parameter search tool with no annotations, the description is complete enough for an agent to call it correctly. It covers costs, caching, filtering behavior, currency conversion, empty results, and sibling routing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 20 parameters thoroughly. The description restates many of the same refinements and adds only marginal extra meaning, so the baseline for high schema coverage is appropriate.

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 starts with a precise verb and resource: 'Search one Amazon store', and adds scope such as 22 countries and default amazon.pl. It clearly distinguishes this from sibling tools by pointing to amazon_compare and amazon_product for different tasks.

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?

It explicitly says when to use alternatives: amazon_compare for several stores at once and amazon_product for one ASIN's offers. The refinement guidance and note that no-result searches are successful outcomes further clarify intended usage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources