Skip to main content
Glama

Nova Amazon MCP Server

list_negative_targets

Read-only

The seller's NEGATIVE keywords and negative product targets — the traffic they deliberately blocked. Answers: is this query already negated, which campaigns block a brand, what did we exclude at the ad-group level. This is a LIST of rules, not metrics: a negation has no spend, no clicks and no period, so there is nothing here to sum or compare — for the spend a query wasted, use query_search_terms. The classic workflow is the pair: query_search_terms with metricFilters spend > X AND sales < 1 gives the negative CANDIDATES, then this tool tells you which of them are already negated. level is where the rule lives (campaign or ad_group), kind is what it blocks (keyword or product_target); a keyword negation carries keywordText + matchType, a product target carries expressionType + expressionValue (an ASIN or a brand id). Requires the ads entity snapshot to be built for the account. 🧭 SPONSORED PRODUCTS ONLY: no Sponsored Brands / Sponsored Display negative list is ingested yet, so adProducts accepts only sponsored_products (any other value is refused with a message saying so, never answered with the SP list under another name) and every row carries adProduct: 'sponsored_products'.

Input Schema

NameRequiredDescriptionDefault
qNoCase-insensitive substring over the negated keyword text AND the product-target expression value.
kindsNoWhat is negated: keyword (a customer query) or product_target (an ASIN/brand).
limitNo
levelsNoWhere the negation lives: campaign or ad_group.
offsetNoRow offset for pagination (default 0).
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.
sortByNo
statesNoAmazon states, e.g. ENABLED.
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.
sortOrderNoasc (default).
adGroupIdsNoRestrict to these ad groups.
adProductsNoWhich ad products' negatives to list. Only sponsored_products is served today; other values are refused by name.
campaignIdsNoRestrict to these campaigns.
marketplacesNoMarketplace IDs.

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?

Beyond the readOnlyHint annotation, it discloses that negations carry no spend/clicks/period (so no aggregation is meaningful), that the ads entity snapshot must be built first, and that only Sponsored Products is served with other adProducts values refused by name. These are exactly the non-obvious behaviors an agent needs.

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?

Front-loads what the tool is, then the workflow, then the level/kind row anatomy, then the SP-only constraint. Dense and useful throughout, though the SP-only restriction is stated twice (description and adProducts schema), which costs a little redundancy.

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?

For a 15-parameter, no-output-schema tool, the description covers the row shape (adProduct, level, kind, keywordText, matchType, expressionType, expressionValue), the prerequisite snapshot, and the ad-product limitation. An agent has everything needed to call it and interpret the result.

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 coverage is already 87%, and the description still adds meaning: `level` is where the rule lives (campaign vs ad_group), `kind` is what it blocks, and it explains which fields a row carries for each kind (keywordText/matchType vs expressionType/expressionValue). It does not add much on q, states, or sort semantics, but that is minor given the strong 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?

States a precise verb and resource: lists the seller's negative keywords and negative product targets, explicitly framing them as blocked traffic. It also distinguishes the tool from query_search_terms and from any metrics tool, so an agent can identify it without opening the schema.

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?

Gives explicit use cases (is this query already negated, which campaigns block a brand, ad-group-level exclusions) and a full workflow pairing query_search_terms as the candidate source with this tool as the negation check. It also names the alternative for spend data, so the boundaries are unambiguous.

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.