Skip to main content
Glama
pangolinfo

Amazon All-in-One Scrape MCP

Official

list_seller_products

Retrieve all products listed by an Amazon seller using their merchant ID. Supports pagination and category filtering to analyze a seller's catalog.

Instructions

[Amazon seller storefront] List all listings under a merchant ID, paginated (24 rows/page). Use when: user says "show me this seller's products" / "how many SKUs does store X carry" / "competitor storefront category breadth" / "what is this seller pushing" / "research a seller's catalog strategy". Don't use: without a merchant ID (find 'sold by' link on any product PDP first); for a single product (use get_amazon_product). Returns: data.json[0].data.{ pageIndex, maxPage, nextPage, results[{ asin, title, price, star, rating, rank, img }] } — 24 rows/page. Two pagination modes: ① page locates a specific page (default 1); ② pageCount accumulates the first N pages in one call (N≤3, flat-merged into the same results). When pageCount>1, pageIndex/nextPage are blanked (pages already merged). Category filter: categoryId filters the seller's products by category. Pair with: ↑ sellerId usually from get_amazon_product's seller.id field, or from amazon.com/sp?seller=... URL; categoryId extractable from the storefront URL's rh=n:; ↓ feed asin into get_amazon_product to deep-dive hero products. Cost: ~1 point/page, ~5s; pageCount=N billed by pages actually crawled (failed pages refunded). Tips: use pageCount to grab the full multi-page SKU set in one shot (max 3 pages); use page to view one specific page; the first page is enough to glance at what the store sells. Amazon first-party sellerId = 'ATVPDKIKX0DER'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sellerIdYesAmazon merchant ID (14-char alphanumeric). Examples: 'ATVPDKIKX0DER' (Amazon.com first-party) / 'A2L77EE7U53NWQ' (Amazon Warehouse). Find it in a product page's 'sold by' link or amazon.com/sp?seller=... URL.
siteNoAmazon marketplace. Defaults to amz_us.amz_us
zipcodeNoZIP code that must match the site country (amz_us → US zip, amz_jp → JP zip, ...). Optional; backend picks a random one from the per-country pool when omitted. Cross-country zips (e.g. amz_us + JP zip) are rejected by the backend. Examples: 10001 (NY) / 90001 (LA) / 100-0001 (Tokyo).
formatNoResponse format. Defaults to 'json' — structured seller listings. Use 'markdown' for the rendered page text.json
pageNoPage number, 1-based. 24 rows per page. Use response's pageIndex/maxPage/nextPage to decide whether to continue: nextPage holds the next page number; nextPage=null or page>=maxPage means last page reached. **Only paginate when the user explicitly asks for more / all SKUs** — otherwise the first page is enough. NOTE: when pageCount>1 (multi-page accumulate) is set, page is ignored (the backend always accumulates from page 1).
pageCountNoMulti-page accumulate: passing N crawls the first N pages in one call and returns them flat-merged (e.g. 3 = all products from pages 1+2+3). Default 1 (single page, uses the `page` flow); cap 3, larger values treated as 3. Difference vs `page`: `page` locates one specific page, `pageCount` pulls the first N pages merged. **Use only when you need the full multi-page SKU set in one shot.** Billed by pages actually crawled (a failed page is refunded).
categoryIdNoCategory filter ID — filters the seller's products by category. A single leaf category ID (e.g. '7161074011'), or comma-separated multi-level categories (e.g. '172282,502394,7161073011'). Omit = all products of the seller. Extractable from the rh=n:<categoryId> part of an Amazon storefront URL.
Behavior5/5

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

With no annotations, the description fully bears the burden of behavioral disclosure. It details two pagination modes (page vs pageCount), how pageCount merges pages, what happens to response fields when multi-page accumulate is used (pageIndex/nextPage blanked), billing (1 point/page), timing (~5s), and error handling (failed pages refunded).

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 well-structured with paragraphs, bullet points, and clear headings. It front-loads the core purpose and usage guidance. While it is lengthy, every sentence adds value – the tool is complex and requires this level of detail. A slight improvement could be further condensing the 'Tips' section into the parameter descriptions.

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?

Despite having no output schema, the description explicitly documents the response structure (data.json[0].data.{ pageIndex, maxPage, nextPage, results[...] }) and explains how to iterate with nextPage. It covers all parameters, two pagination modes, category filtering, marketplace defaults, and integration with sibling tools. For a 7-parameter tool with multiple modes, this is very complete.

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?

The input schema already has 100% coverage, but the description adds substantial context: how to find sellerId (from product page 'sold by' link or amazon.com/sp URL), zipcode cross-country rejection, the difference between page and pageCount (one locates a specific page, the other accumulates), and how to extract categoryId from storefront URL. This goes far beyond what the schema alone provides.

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 and resource: 'List all listings under a merchant ID, paginated (24 rows/page).' It immediately communicates the tool's scope (entire catalog of a seller) and distinguishes it from single-product tools like get_amazon_product.

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?

The description provides extensive usage guidance: explicit use cases ('show me this seller's products', 'competitor storefront category breadth'), a clear 'Don't use' section (requires merchant ID, not for single product), and pairs with sibling tools (get_amazon_product for deep-dives). It even explains how to extract the required sellerId.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pangolinfo/pangolinfo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server