Skip to main content
Glama

Nexscope Ecommerce Data MCP

Amazon ABA & Business Insights: intelligent Query API

nexscope_data_aba_intelligent_query

Amazon ABA & Business Insights: intelligent Query API.

Input Schema

NameRequiredDescriptionDefault
regionNoAmazon site code. Optional values: `US`, `DE`, `BR`, `CA`, `AU`, `JP`, `AE`, `ES`, `FR`, `IT`, `SA`, `TR`, `MX`, `SE`, `NL`.US
createDownloadUrlNoWhether to generate a CSV download link; set to `true` when explicitly required to download, export or generate files.
analysisDescriptionYesNatural language that accurately describes query intent.

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?

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent knows this is not a simple read and reaches outside the system, yet the description explains none of that. It does not mention that a CSV download can be produced (createDownloadUrl), what kinds of analyses are permitted, or anything about cost, latency, or auth.

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 wasted words, but it is content-free — a restatement of the title rather than front-loaded information. Being short here reflects under-specification rather than disciplined concision.

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 an open-world natural-language query tool with no output schema, the description should at minimum indicate the kinds of questions it can answer and what a response looks like. It provides none of that, leaving the agent unable to form a valid analysisDescription with confidence.

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 region, createDownloadUrl, and analysisDescription are all documented in the schema itself. The description adds no additional meaning, but with full schema coverage the baseline of 3 applies.

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 restates the title almost verbatim ('Amazon ABA & Business Insights: intelligent Query API') without a concrete verb or resource outcome. It hints at a domain (ABA / Business Insights) and a natural-language query mechanism, but an agent cannot tell what it actually returns or how it differs from the many keyword/intelligence siblings.

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 when-to-use guidance, no exclusions, and no named alternative despite dozens of adjacent tools (nexscope_amazon_keyword_intelligence, nexscope_data_sf_asin_summary, nexscope_amazon_market_research). The agent is left to guess when this natural-language query path is preferable to a structured tool.

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