Skip to main content
Glama

Nova Amazon MCP Server

query_search_terms

Read-only

The actual customer SEARCH QUERIES behind Sponsored Products and Sponsored Brands spend — the search-term report, same pipeline as the app (Sponsored Display has no search-term report: asking for it is refused by name). Answers: what customers really type before clicking an ad, negative-keyword candidates (queries with spend and zero sales), auto-campaign discoveries worth promoting to exact match. groupBy="searchTerm" is the main drill-down; the ad product (adProduct), ad-structure grains (portfolio/campaign/adGroup/targetingType/targetingDetail/keyword) and TIME grains also work (adProduct and portfolio need the stacked-cut ads fact and are otherwise refused with a message naming ADS_FACT_ENABLED). Metric universe = the ads keys MINUS impressions/ctr (biased at this grain, rejected) and MINUS the seven brand keys (newToBrand*, videoCompleteViews, viewableImpressions, brandedSearches, topOfSearchImpressionShare — the search-term reports carry none of them) and MINUS the four profit keys (this grain carries no ASIN, so there is no product margin to price a query at — use query_advertising for those): spend, sales, sales14d, clicks, orders, units, units14d, acos, roas, cpc, cvr. NO product (ASIN/SKU) dimension or filter exists here — the search-term report carries no ASIN attribution; for per-product ads use query_advertising. Rows with search term '*' are PDP placements with no typed query. ⚠️ groupBy="searchTerm" serves CLICKED QUERIES ONLY: a query with 0 clicks over the requested period is not served, and rows, summary.count and summary.total all follow that rule (Amazon also emits 0-click / 0-spend rows carrying attribution-window sales; they used to top every ACOS-ascending sort at a fake 0.0%). It is a PERIOD rule, not a daily one — a query clicked on one day keeps the sales its other days attribute. ACOS is null, never 0, when nothing was spent. 🚫 Each searchTerm row carries attrs.negatedLevel ('campaign' | 'ad_group' | null): a keyword negative on that EXACT text already blocking the traffic THIS row is made of — a campaign the row spent in, or an ad group it spent in. A negative in a SIBLING ad group is NOT reported: the query is still costing money where you are looking. Expect it to be null almost everywhere and do not read that as "nothing is blocked" — a negative that works stops the query being served, so it leaves this report entirely; what lights up is a query negated DURING the period. For "have I ever blocked this anywhere", use list_negative_targets with q = the term. ⚠️ Never cross-sum with query_metrics' ad metrics. 🧭 AD PRODUCTS: the console serves Sponsored Products, Sponsored Brands, Sponsored Brands Video and Sponsored Display as DISJOINT blocks of rows — adProducts picks which (default ['sponsored_products'] until the fact serves the others; pass several to read them in ONE call, or groupBy='adProduct' to split the money by product). Each block is read from its own cut of the fact at its OWN attribution window: SP orders/sales/units are 7-day on a Seller Central account and 14-day on a Vendor Central account (each console's own window), SB and SBV 14-day, SD 14-day CLICK-attributed (view-attributed SD conversions are never included) — so never sum or compare sales, orders, ACOS or ROAS across products; spend is the ONE additive column across all four, sponsored_brands + sponsored_brands_video (one report, split per row) the ONE additive pair, and sales14d / units14d the like-for-like 14-day reading. Sponsored Display has no search-term and no placement report (such a call is refused by name). Entity rows carry attrs.adProduct; it is null on a VALUE row (an ASIN, a placement, a targeting type, a search term) that folds two products. 💱 CURRENCY: monetary values are served in the caller's Nova display currency when it is one of the organization's configured currencies (its primary or up to four secondary currencies), else in the organization's primary. In the response, currency is the code, currencyBasis says why (user_preference | organization | pinned) and currencyNotice, when present, MUST be relayed to the user. Quote the code; never assume a symbol from the marketplace. Pass currency to pin any configured code — e.g. to reproduce a figure the seller read on a dashboard set to another currency.

Input Schema

NameRequiredDescriptionDefault
toYesPeriod end, INCLUSIVE (YYYY-MM-DD): a calendar month is from=YYYY-MM-01 to=its LAST day. to=the 1st of the next month adds one extra day to every total (and one extra bucket with a time grain).
fromYesPeriod start, INCLUSIVE (YYYY-MM-DD).
limitNoRows per call of an entity grouping, 1 to 1000 (default 50). A time grain is never cut: its series comes whole, in date order, 1000 buckets at most.
reasonNoOne sentence, ALWAYS IN ENGLISH (regardless of the conversation language), on WHY you are making this call — the user question or your analytical goal. Recorded so the seller can see how their data is used.
sortByNoMetric key of THIS universe to rank rows by (e.g. "spend"). Refused with a time grain: a series comes in date order.
groupByNosearchTerm (the main drill-down), the ad product (adProduct), an ad-structure grain (portfolio/campaign/adGroup/targetingType/targetingDetail/keyword), or a time grain. Omit for a single total row.
metricsYesADS metric keys minus impressions/ctr and minus the profit keys — NOT product keys from list_metrics.
accountsNoRestrict to a subset of your own seller account IDs (from list_accounts). Omit to include all your accounts. A brand/account name is accepted and resolved to its id when it matches one of your accounts unambiguously; a label that carries the id ("Brand (A1B2C3D4E5F6G)") resolves to that id.
channelsNoONE Amazon programme per call. 'SELLER' = Seller Central (3P) advertising: the seller's own Amazon Ads campaigns. 'VENDOR' = Vendor Central (1P) advertising: the campaigns of the vendor's own Amazon Ads profile. Omit = SELLER whenever the accounts of the call include a Seller Central account, else VENDOR. Pass ['VENDOR'] only when the user asks about Vendor Central / 1P advertising. Both at once is refused: 3P and 1P spend and sales are never added into one total.
currencyNoPin the reporting currency: one of the organization's configured codes — its primary or any of its secondary currencies (e.g. "USD"). Omit to follow the caller's Nova display currency, the dashboard's rule. Any other code is refused.
sortFieldNoWhat to rank on: 'value' (default), or 'variance' / 'variancePercentage' (need a comparison period).
sortOrderNodesc (default) = biggest first.
adGroupIdsNo
adProductsNoWhich ad products to read, as disjoint blocks: sponsored_products, sponsored_brands, sponsored_brands_video, sponsored_display. Default ['sponsored_products'] until the fact serves the others. Each has its own attribution window and history floor — see the AD PRODUCTS note.
keywordIdsNo
campaignIdsNo
searchTermsNoExact customer queries to keep (identity filter).
comparisonToNoBaseline period end (inclusive).
marketplacesNoMarketplace IDs.
portfolioIdsNoPortfolio ids — needs the stacked-cut ads fact (ADS_FACT_ENABLED).
metricFiltersNoServer-side threshold filters (ANDed) — e.g. spend > 20 AND sales < 1 for negative-keyword candidates. Needs an entity grouping.
comparisonFromNoBaseline period start (inclusive) — enables variance.
targetingTypesNoe.g. keyword, auto, product, category.
targetingDetailsNo
excludeUnfinishedNoExclude the current, still-incomplete period so a partial day/week/month is not read as a drop.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint; the description carries the rest of the burden and does so densely — clicked-queries-only serving for groupBy='searchTerm', non-additivity of sales/orders/ACOS across ad products with the single additive column named, per-product attribution windows, null-vs-0 ACOS semantics, and currency resolution/relay rules. Far beyond what annotations or schema state.

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

Conciseness3/5

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

The lead sentence is well front-loaded, but the body is a wall of prose with emoji-tagged asides that drifts toward reference documentation — Sponsored Display's lack of a search-term report is stated twice, and the AD PRODUCTS paragraph is long enough to be skimmed past. For a 25-parameter tool the density is defensible, but it is not tight.

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?

No output schema exists, and the description compensates: it explains the response's `currency`/`currencyBasis`/`currencyNotice` fields, `attrs.negatedLevel` and its null caveat, summary.count/total semantics under the click rule, and the '*' PDP placeholder. An agent has enough to call and interpret results correctly.

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

Parameters5/5

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

Schema coverage is already 84%, but the description adds real meaning the schema lacks: the exact metric universe (which ads keys are rejected and why), what each groupBy actually resolves to at this grain, the adProducts default and its disjoint-block behavior, and currency pinning semantics. This is additive, not restated.

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?

Opens with a specific verb+resource: "The actual customer SEARCH QUERIES behind Sponsored Products and Sponsored Brands spend — the search-term report." It immediately names the questions it answers (negative-keyword candidates, auto-campaign discoveries) and explicitly disclaims Sponsored Display, so an agent can separate it from query_advertising and query_metrics.

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?

Explicit routing throughout: use query_advertising for per-product ASIN metrics, query_metrics is never cross-summed, list_negative_targets with `q` for "have I ever blocked this", groupBy='adProduct' to split the money. It also spells out refusal conditions (Sponsored Display search-term calls, portfolio/adProduct without ADS_FACT_ENABLED) so the agent knows what will fail before calling.

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.