Skip to main content
Glama
Data-Dive-Tools

DataDive MCP

Official
by Data-Dive-Tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Search Query Performance for a Rank Radar

get_rank_radar_sqp_data
Read-only

Retrieve Amazon Search Query Performance (SQP) data for Rank Radar keywords over a date range to analyze search volume, impressions, clicks, cart adds, purchases, and ASIN share.

Instructions

Use this when the user asks how shoppers search, click, add to cart and buy for the keywords of a Rank Radar — Amazon's Search Query Performance (SQP) data, from Brand Analytics. Requires startDate and endDate (yyyy-mm-dd), at most 90 days apart; 30 days or less keeps it fast. Each keyword's metrics are aggregated over the range: searchQueryVolume and searchQueryScore; impressions, clicks, cart adds and purchases, each as the total across all sellers (*TotalCount), this ASIN family's count (*AsinCount) and its share (*AsinShare); click, cart-add and purchase rates; and ctr/cvr for the market (*Total) and for this ASIN family (*Asin). numberOfDaysWithData says how many days of the range had SQP data; metrics are null when there is none, which is normal for low-volume keywords, recent dates (Amazon publishes SQP with a delay) and sellers without Brand Analytics. Results are paged by keyword: data holds one page, and the response carries currentPage, pageSize, total, lastPage, hasNext and hasPrev. total is the Rank Radar's active keyword count; to read every keyword, call again with currentPage + 1 while hasNext is true, using pageSize 100 for large Rank Radars. Paused keywords are not included. Each call counts toward API usage and is rate limited (about 60 requests/minute). Use after list_rank_radars to discover a rankRadarId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endDateYesEnd date of the range, yyyy-mm-dd (e.g. 2024-04-26). Must be on or after startDate, and at most 90 days after it.
pageSizeNoKeywords per page (max 100). Defaults to 20.
startDateYesStart date of the range, yyyy-mm-dd (e.g. 2024-03-26).
currentPageNoPage of keywords, 1-indexed. Defaults to 1.
rankRadarIdYesThe Rank Radar UUID (from `list_rank_radars`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.16.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only provide readOnlyHint=true, but the description adds substantial behavioral context: rate limiting (~60 requests/minute), API usage cost, pagination mechanics, null handling for low-volume keywords, SQP publication delay, and the fact that paused keywords are excluded. This goes well beyond structured annotations.

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 long but well-organized and front-loaded with the primary use case. Each sentence carries information, though some details (e.g., metric field breakdown) could be considered dense. It remains efficient for the complexity of the tool.

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?

There is no output schema, so the description must explain return values, which it does thoroughly: metric naming conventions (*TotalCount, *AsinCount, *AsinShare), rate fields, null conditions, and pagination response fields. Combined with the parameter and behavioral coverage, the description is complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds useful performance guidance ('30 days or less keeps it fast') and pagination usage advice ('pageSize 100 for large Rank Radars', 'call again with currentPage + 1 while hasNext is true'), which enriches parameter understanding 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?

The description states a specific verb (get) and resource (Search Query Performance data for a Rank Radar), and explicitly identifies the data source (Amazon Brand Analytics). It distinguishes from siblings like get_rank_radar_data and get_rank_radar_ppc_data by focusing on shopper search/click/cart/purchase metrics for keywords.

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

Usage Guidelines4/5

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

It gives a clear use case ('when the user asks how shoppers search, click, add to cart and buy for the keywords of a Rank Radar') and a prerequisite ('Use after list_rank_radars'). It does not explicitly name alternative tools or state when not to use this one, but the context is strong enough to route the agent correctly.

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