Skip to main content
Glama

Nexscope Ecommerce Data MCP

Amazon Niche Intelligence JM: get Niche Info API

nexscope_data_jm_get_niche_info

Amazon Niche Intelligence JM: get Niche Info API.

Input Schema

NameRequiredDescriptionDefault
nicheIdYesMarket segment ID, maximum length 1000 characters, only supports single ID query
countryCodeNoCountry code, only supports `US`, `JP`, `DE`, the default is `US`US

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

D1.8/5.0
Behavior1/5

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

The description contributes nothing beyond the annotations (readOnlyHint=false, openWorldHint=true), which are themselves non-obvious for a 'get' tool and would benefit from explanation. It does not say whether the call hits live data, whether it is expensive or rate-limited, or what side effects justify readOnlyHint=false. No annotation contradiction, but a total absence of behavioral context.

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

Conciseness2/5

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

One short sentence with no waste, but it is under-specified rather than concise: the sentence merely echoes the tool name and conveys no information an agent could act on. Front-loading is moot when the content is a title repeat.

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

Completeness2/5

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

For a niche-intelligence retrieval tool with no output schema and non-default annotations, an agent needs to know what 'niche info' contains and how it differs from the by_asin/by_keyword variants. None of that is present, leaving the definition incomplete despite the modest two-parameter surface.

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 explains nicheId (max 1000 chars, single ID only) and countryCode (US/JP/DE, default US). The description adds nothing to parameter meaning, which is acceptable only because the schema carries the full burden — baseline 3.

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

Purpose2/5

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

The description is a restatement of the title: 'Amazon Niche Intelligence JM: get Niche Info API.' It does name a verb ('get') and a resource ('Niche Info'), but it adds no detail about what niche data is returned or for what purpose. Siblings such as nexscope_data_jm_get_niche_info_by_asin and nexscope_data_jm_get_niche_info_by_keyword are not distinguished, so an agent cannot tell which niche-lookup tool to pick.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus the near-identical siblings (get_niche_info_by_asin, get_niche_info_by_keyword, get_niche_review_from_keyword). The only hint is the parameter name 'nicheId', which the agent must infer means this is the ID-based lookup variant. No prerequisites or exclusions are stated.

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