Skip to main content
Glama

Query keyword rank trends

query_keyword_rank_trends
Read-only

One trackingScope per request: PARENT (default) uses parentAsin and tracks the family; CHILD uses asin and tracks only that exact variation, excluding siblings. The server resolves its parent. For tracker lists use parentAsins with PARENT or asins with CHILD. Query, ADD, RESUME, REMOVE and SET_COMPETITORS must preserve the same scope and target. Both OWN_PRODUCT and independent COMPETITOR support CHILD. For OWN_PRODUCT associations, PARENT competitorAsins are parent/standalone ASINs while CHILD competitorAsins are exact variation ASINs. includeCompetitors compares the same scope. Account capabilities and notices are returned even for empty results. Check advertisingRankTracking before interpreting advertising ranks or offering advertising tracking. False means unsupported, not a missing match; never promise advertising ranks or silently substitute organic tracking for an explicit advertising-rank request. This applies to own products, independent competitors, and associated competitors. First discover tracked products and keywords with query_keyword_rank_trackers (all matching configuration is returned without pagination). For DAILY, provide one storeId, one scope-specific ASIN and 1 to 10 exact tracked keywords, plus startDate/endDate (up to 90 inclusive marketplace-local days). All requested daily points return in one response; there is no offset/limit pagination. Split more than 10 keywords into separate requests. Each day keeps the last actual observation; absent days are not synthesized. Equal-time ties use child ASIN descending, current source first, then ID descending, not best rank. RAW uses the same storeId and scope-specific ASIN with exactly one keyword, supports 31 inclusive days, and uses offset and limit (default and maximum 100) over observation points; increase offset by limit until fewer than limit points are returned. RAW preserves distinct child ASINs and prefers current records over archived copies. One product type per request: OWN_PRODUCT (default) or independent COMPETITOR. Call separately for each type; ALL and mixed selections are not supported. Competitors share account-wide marketplace/keyword quota with owned products. MCP reporting and workflow metric date ranges use yyyy-MM-dd and include both startDate and endDate, with at most 95 calendar days per range. For longer read-only reports, split into non-overlapping windows: endDate = startDate plus 94 days, capped at the requested end date; the next startDate is the previous endDate plus 1 day. Apply the same limit independently to comparison ranges. Do not average ratios such as ACOS or ROAS across windows; recompute them from summed base metrics. Do not automatically split advertising write plans or metric-based selectors; obtain a supported analysis window from the user. Keyword ranking trends have separate limits: DAILY supports up to 90 inclusive days and RAW up to 31 inclusive days. For keyword ranking trends, use these interval-specific limits when splitting read-only reports. This reporting limit does not apply to campaign scheduling dates.

Input Schema

NameRequiredDescriptionDefault
asinNoRequired exact child ASIN for CHILD; omit parentAsin.
limitNoRAW only: maximum observation points per page, default and maximum 100. Does not limit DAILY results.
offsetNoRAW only: zero-based observation offset. DAILY requires 0.
endDateYesRequired inclusive end date in yyyy-MM-dd, interpreted in each store's marketplace time zone.
storeIdYesOne authorized store ID in sellerId:marketplaceId format.
intervalNoTrend resolution. DAILY keeps the final stored observation in each marketplace-local day, up to 90 inclusive days. Ties use child ASIN descending, current source first, then ID descending. RAW reads one product keyword over up to 31 inclusive days, with offset/limit pagination over observation points. Increase offset by limit; stop when fewer than limit points are returned.DAILY
keywordsYesExact tracked keywords for this product: DAILY 1 to 10, RAW exactly one. DAILY returns the full requested history without pagination.
startDateYesRequired inclusive start date in yyyy-MM-dd, interpreted in each store's marketplace time zone.
parentAsinNoThe selected product's tracked parent ASIN.
productTypeNoOne product type per request: OWN_PRODUCT (default) or independent COMPETITOR. Call separately for each type; ALL and mixed selections are not supported. Competitors share account-wide marketplace/keyword quota with owned products.OWN_PRODUCT
trackingScopeNoPARENT (default) tracks a parent family using parentAsin. CHILD tracks only the specified variation using asin; omit parentAsin. Never silently substitute a parent or sibling. Applies to OWN_PRODUCT and independent COMPETITOR. SET_COMPETITORS supports both scopes for OWN_PRODUCT: parent/standalone competitors for PARENT, exact child competitors for CHILD.PARENT
includeCompetitorsNoInclude currently associated competitors' stored histories for the same keyword and trackingScope. OWN_PRODUCT + DAILY only, exactly one keyword, at most 31 inclusive days and 10 associated competitors. PARENT compares parent families; CHILD compares exact associated variations. Compare observedAt before comparing ranks; empty points mean no stored history. This is not independent COMPETITOR tracking.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond readOnlyHint/destructiveHint/openWorldHint, the description adds substantial operational behavior: empty-result account notices, quota sharing, no DAILY pagination, RAW offset/limit pagination, tie-breaking rules, absence of synthesized days, and advertising-rank fallback semantics. It meaningfully reduces ambiguity about what the server will and will not return.

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?

The description is extremely long and dense, with repeated date-window and DAILY/RAW limitations across several paragraphs. It is not front-loaded around the tool's core operation, and multiple sentences repeat constraints already stated elsewhere in the description or schema.

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?

Given 12 parameters, complex scope/date/pagination rules, annotations, and an output schema, the description is complete enough for correct invocation. It covers the major edge cases, limits, exclusions, and advertising-rank caveat, even though it is overlong.

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 schema already carries most parameter definitions; the description mainly reinforces those. It still adds useful cross-parameter semantics, especially scope-preservation across operations, productType separation, parent-vs-child competitorAsin meaning, and includeCompetitors' narrow OWN_PRODUCT+DAILY constraints.

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?

The description identifies keyword ranking trends and clearly separates the tool from query_keyword_rank_trackers by pointing to that sibling for discovery. It explains the DAILY vs RAW modes and scope behavior, but it opens with detailed constraints rather than a concise statement of the tool's core purpose.

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?

It gives explicit when-to-use rules: discover trackers with query_keyword_rank_trackers first, choose DAILY for up to 10 keywords and 90 days, RAW for one keyword and 31 days, and call separately per productType. It also names exclusions such as ALL/mixed selections and clarifies how to interpret advertising-rank capability.

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