Skip to main content
Glama
Pangolin-spg

Pangolinfo Amazon Data MCP

by Pangolin-spg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

filter_niches

Filter Amazon niches by 50+ metrics like search volume, competition, and return rate to find blue-ocean opportunities, or get a deep report on one niche.

Instructions

[Amazon niche filter] Filter Amazon Niches (a finer-grained "demand cluster" than categories) by 50+ commercial metrics, or use as a "niche detail" endpoint for one niche. Use when: user says "find blue ocean" / "high search volume + low competition niches" / "fast-growing small markets" / "niche scouting" / "give me the deep report on this niche" / "low return-rate niches" / "niches with return rate under 10%"; the core filter step of GTM scouting SOPs; getting fee structure / brand age / new-launch trends for one niche. Don't use: for full categories (use filter_categories); for actual products in a niche (the niche record only carries 1 referenceAsin; combine with categoryId + list_category_products); for plain keyword search (use search_amazon). Returns: data.items.data[{ nicheId, nicheTitle, referenceAsinImageUrl, currency, searchVolumeT90, searchVolumeT360, searchVolumeGrowthT90, minimumPrice, maximumPrice, avgPrice, productCount, sponsoredProductsPercentage, primeProductsPercentage, top5ProductsClickShare, top20BrandsClickShare, brandCount, sellingPartnerCount, avgBrandAge, avgBestSellerRank, avgProductPrice, avgReviewCount, avgReviewRating, avgDetailPageQuality, newProductsLaunchedT180/T360, successfulLaunchesT90/T180/T360, returnRateT360, fee fields T365 … 100+ fields }] + data.items.pagination.{ total, page, size, hasNext }. Pagination: use the 'page' param (default 1, 1-based, size capped at 10 (default 3)); 'pagination.hasNext=true' means more pages exist, 'hasNext=false' means last page. Pair with: ↑ marketplaceId required (defaults US); nicheTitle for keyword filter, nicheId for single-niche detail; ↓ feed referenceAsin into get_amazon_product to see the representative product; niche doesn't carry a categoryId directly — derive separately if needed. Cost: ~1 point/call, ~5s. Tips: size capped at 10 (default 3); pass long-tail filters (50+ fields) via extraFilters; classic blue-ocean combo = high searchVolumeT90Min + low top5ProductsClickShareT360Max + moderate productCountMax + positive searchVolumeGrowthT90Min + returnRateT360Max ≤ 0.10 (low-return). For return-rate filtering use returnRateT360Max (upper bound, 0-1 decimal); the response includes returnRateT360 with the actual return rate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, 1-based.
sizeNoPage size, max 10 (backend hard limit), default 3 (small default to keep responses under AI context limits — pass size=10 explicitly when you need a wider sweep).
nicheIdNoWhen set, returns the full deep report for that single niche (this endpoint doubles as the niche-detail endpoint). Omit to list multiple niches matching the filters. Example: '8140a265-768d-4679-8bc2-994cb1c96f0b' (UUID).
sortFieldNoSort field; any response field name is accepted (e.g. 'searchVolumeT90', 'avgProductPrice').
sortOrderNoSort order: 'asc' or 'desc'.
nicheTitleNoKeyword match against niche titles. Examples: 'iphone 16 wallet case' / 'wireless earbuds for sports'.
clientSourceNo调用来源标记。仅由 Pangolinfo Skill 传 skill；普通 MCP 调用省略即可。
extraFiltersNoPass-through for any other upstream filter (e.g. sponsoredProductsPercentageT360Min, successfulLaunchesT360Max, avgBestSellerRankMax). Keys must match the upstream doc verbatim.
marketplaceIdNoAmazon marketplace id (required). ⚠️ Backend currently supports US only; other marketplaces will fail or fall back. Use US (the default).US
maximumPriceMaxNoUpper bound on the niche's maximum product price.
minimumPriceMinNoLower bound on the niche's minimum product price.
productCountMaxNoMax product count in the niche.
productCountMinNoMin product count in the niche.
avgReviewCountMaxNoMax average review count — lower means less competition.
avgReviewCountMinNoMin average review count.
returnRateT360MaxNoMax return rate over 360 days (0-1).
avgReviewRatingMinNoMin average review rating (0-5).
searchVolumeT90MaxNoMax search volume over last 90 days.
searchVolumeT90MinNoMin search volume over last 90 days.
searchVolumeT360MaxNoMax search volume over last 360 days.
searchVolumeT360MinNoMin search volume over last 360 days.
searchVolumeGrowthT90MaxNoMax 90-day search-volume growth rate.
searchVolumeGrowthT90MinNoMin 90-day search-volume growth rate (decimal, 0.1 = +10%).
top5ProductsClickShareT360MaxNoMax top-5-products click share over 360 days (0-1). Lower = more fragmented niche, more opportunity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.9/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: it discloses pagination semantics (hasNext, page, size cap), a hard marketplace limitation (US only, others fail/fall back), cost (~1 point/call, ~5s), and the fact that size is capped at 10. These are the operational traits an agent needs that structured fields do not supply.

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-loaded with purpose, then Use/Don't-use/Returns/Pair-with/Cost/Tips in a scannable order. It is dense and long, and the Returns field list is somewhat verbose, but nearly every line aids correct invocation, so little is wasted.

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 24-parameter, no-output-schema tool, the description supplies the return shape (so no output schema is needed), pagination behavior, pairing guidance (get_amazon_product, categoryId derivation), and the missing-categoryId caveat. Nothing an agent needs to call it correctly is absent.

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: it explains extraFilters as the pass-through for 50+ long-tail filters, gives the concrete blue-ocean filter combo with the correct field names, clarifies returnRateT360Max as a 0-1 upper bound, and notes marketplaceId defaults to US. This is genuine value beyond the schema.

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 ('Filter Amazon Niches') and immediately disambiguates the concept ('a finer-grained demand cluster than categories'), plus discloses a dual mode ('niche detail' endpoint for one niche). An agent can distinguish this from filter_categories and list_category_products without opening any 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?

Explicit 'Use when' section with concrete user utterances (blue ocean, low return-rate, niche scouting) and an explicit 'Don't use' section naming the correct siblings for full categories, products in a niche, and plain keyword search. Routing is unambiguous.

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

Deploy Server

Other Tools