Skip to main content
Glama
apiguru-app

apiguru-amazon-data

Best-seller rankings for a category

best_sellers
Read-onlyIdempotent

Fetch ranked Amazon product listings by department, marketplace and page, returning resolved category names, subcategory ids and each product's rank.

Instructions

Best-seller rankings for a department of one marketplace, 50 per page. Every answer carries the department it resolved to and how (category_resolution: by slug, name or a fragment of a name, with a hint when a fragment such as 'shoes' landed on the whole 'Clothing, Shoes & Jewelry' department), available_categories (that marketplace's departments with slugs) and available_subcategories (the children of the node shown, with the ids subcategory_code takes). On amazon.com subcategory_code also takes any browse node id at any depth, or a name resolved under the department ("women's shoes", "mules & clogs"); category.subcategory_path gives the node's full path and category.heading the page's own title line. Price: $0.003 per call. No required parameters - calling it bare returns US appliances page 1. category accepts a slug, a display name, one of the older US department names, or a unique fragment; category_resolution.via says which, and a fragment match adds a hint naming the subcategories that carry the word, with ids. On amazon.com the whole browse tree is known: subcategory_code takes any node id or a name at any depth, subcategory_name and subcategory_path are filled without a fetch, and available_subcategories lists the node's real children (empty on a leaf). Other marketplaces name only what their navigation showed. page is capped at 5 (a 400 beyond, not a 500). rank is the position within the requested list on this page. Rows are the same for every marketplace; only the department vocabulary differs, and the answer carries it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
geoNoMarketplace country code.US
pageNoResult page, 1-based, 50 rows each; Amazon's lists stop at page 5.
limitNoHow many ranked products to return from this page (0 = all of them). A full page is up to 48 rows and about 54 KB, which most clients spill to a file instead of showing inline. The answer carries _truncated with the true count when it trims.
fieldsNoComma-separated row fields to return instead of the light set, e.g. "asin,product_title,product_price". Rows list what they left out under _omitted_fields.
compactNoReturn light rows: identity, price, rating, badges and one delivery_date, dropping the long delivery prose that repeats itself across three fields. false returns every field the REST API sends (roughly 3x the size).
categoryNoBest-seller department, by slug or by name as Amazon shows it for that marketplace (case-insensitive; a unique fragment works, and the answer's category_resolution says when a fragment was used -- 'shoes' is the whole 'Clothing, Shoes & Jewelry' department, and the hint then lists the Shoes subcategories with their ids). Departments and their slugs differ per marketplace: amazon.com has electronics, amazon.de has ce-de (Electronics & Photo). Every answer lists that marketplace's departments under available_categories; an unknown or ambiguous name is a free 400 listing them.appliances
subcategory_codeNoBrowse node id under `category`: one from available_subcategories of a previous answer, or on amazon.com any node id at any depth (679410011 is Women > Shoes > Mules & Clogs) or a name resolved under the department ("women's shoes", "mens boots", "mules & clogs"). A name that fits two nodes equally (Men > Shoes > Boots and Women > Shoes > Boots) is a free 400 listing both ids with their paths.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
pageNo
successNo
categoryNo
max_pageNo
page_sizeNo
request_idNo
category_resolutionNo
available_categoriesNo
available_subcategoriesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With annotations already covering read-only/idempotent/open-world semantics, the description adds substantial non-obvious behavior: $0.003 per call pricing, page capped at 5 returning a 400 rather than 500, free 400s for unknown categories, and truncation behavior. This is real value beyond the structured fields.

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 is front-loaded, but the prose is long and repetitive - the amazon.com any-depth/fragment behavior and the per-marketplace department vocabulary are each stated more than once. Several sentences could be consolidated without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-required-param tool with an output schema, the description covers the department-resolution vocabulary and error behavior an agent needs. It is close to complete, with only minor redundancy rather than a genuine gap.

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 the baseline is 3, but the description adds meaning beyond it: fragment resolution via category_resolution.via and its subcategory hint, the amazon.com any-depth node-id rule, and the ambiguous-name 400 behavior. Some of this restates the schema, so it lands at 4 rather than 5.

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+scope up front ('Best-seller rankings for a department of one marketplace, 50 per page'), which cleanly distinguishes it from siblings like search, deals and product_details. An agent can identify the tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It conveys useful usage context - no required parameters and a bare call returns US appliances page 1 - but never states when to choose this over siblings such as search or deals, nor any explicit exclusions. Usage is implied rather than spelled out.

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