tool4seller-mcp

Query category insights

query_category_insights

Read-only

Returns marketplace category summaries and metrics by category keyword or ASIN. ASIN searches return category-level data. Without a search, lists categories ranked by search volume.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "marketplaceId": "<marketplaceId>"
    },
    "name": "query_category_insights"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Page size. No total count is computed.
`offset`	No	Zero-based offset. offset + limit must not exceed 10000.
`period`	No	Source reporting window, not a custom date range. Features are a separate snapshot and year-over-year series retain their own dates.	LAST_30_DAYS
`sortBy`	No	Summary metric to rank categories. Seller sorting uses the lower bound. Defaults to searchVolume.	searchVolume
`searchKey`	No	Category name keyword or ASIN. Exactly ten alphanumeric characters use Catalog BSR category matching, as on PC; other text searches localized category names. Omit to browse the market.
`sortOrder`	No	Sort direction.	desc
`marketplaceId`	Yes	Amazon marketplace ID.
`productTypeId`	No	Optional product type ID, combined with other filters.
`rootCategoryId`	No	Optional root category ID, combined with other filters.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the meaningful caveat that an ASIN search still returns category-level rather than product-level data, plus the default browse-and-rank behavior. It adds little beyond that – pagination caps and the 10,000 offset ceiling live in the schema, not here.

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

Conciseness5/5

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

Three short sentences with zero filler, front-loaded with the core return value and then the two operational modes. Nothing is redundant or buried.

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?

With a full output schema, rich parameter documentation, and safety annotations, the description only needs to establish purpose and modes – which it does. The one gap is its relationship to query_category_insight_detail, which an agent would need in order to choose between the summary and detail tools.

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 every one of the nine parameters is already documented, including the ten-alphanumeric-character ASIN rule and the default searchVolume sort. The description restates the searchKey and ranking behavior rather than adding format, precedence, or interaction details, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Returns marketplace category summaries and metrics") plus the lookup key (category keyword or ASIN), so the agent knows exactly what it retrieves. It does not distinguish itself from the sibling query_category_insight_detail, which reads as a detail-drilldown counterpart, leaving that routing decision ambiguous.

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?

"ASIN searches return category-level data" and "Without a search, lists categories ranked by search volume" describe what each input mode produces, which implies when to use each. However, there is no explicit when-to-use framing, no when-not guidance, and no mention of the alternative query_category_insight_detail for deeper data.

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

All tool4seller-mcp tools Inspect

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

Need Help?