Skip to main content
Glama

Nova Amazon MCP Server

query_listing_health

Read-only

Current listing-health STATE per SKU — the same source as the app's Listing Health page, so statuses, suppression flags, and severity match the dashboard. Point-in-time entity state (NOT a metrics/date-range query — no from/to). Each row has: status, is_buyable, the per-issue flags (is_removed, is_suppressed, is_search_suppressed, is_attribute_suppressed, image_not_applied, is_compliance_risk, is_quality_issue, is_incomplete — a listing Amazon reports buyable is never is_suppressed: Amazon lists LISTING_SUPPRESSED on buyable, selling listings, so that notice counts as is_quality_issue instead; an action Amazon marks exempt never lights a flag), a severity_label + health_summary + the driving issue (top_issue_code/message/enforcement), the worst-wins alert_band (0 cash-loss · 1 degraded · 2 watch · 3 none), trailing-90d sales/units, the buy-box competition block (buy-box owner/price, hijack entrant, price undercut, contested), and a content block with the PUBLISHED catalog content (brand, manufacturer, productType, browse node id+name, variationTheme, bulletPoints, productDescription, mainImageUrl full-size — NOT the small imageUrl render — imageCount, contentLanguage) plus the seller's SUBMITTED backendKeywords. Content gotchas: catalog fields are NULL until the catalog capture covers the ASIN (gate: contentFetchedAt=null); keywordsScanned=false means the Listings scope has not reached this SKU yet — backendKeywords NULL then means 'not looked at', never 'none written'. Answers: which listings are removed / suppressed / not buyable right now, what to fix first, who is losing the buy box, and content audits (missing bullets/description/backend keywords, image count, wrong content language). Filter by problems (per-issue checks), bands, or statuses; sort='severity' surfaces the worst listings first. CHANNELS: omit channels to read the Seller Central (3P) listings whenever the accounts of the call include a Seller Central account, else the Vendor Central (1P) ones (a vendor-only scope, or a Vendor Central account named alone in accounts); pass channels=['VENDOR'] for the Vendor Central (1P) listings, or ['SELLER','VENDOR'] for both in one list (next to a Seller Central account, a Vendor Central account is read only when VENDOR is asked for; a channel none of the accounts of the call sells on returns an empty list, not an error). Each row carries channel ('SELLER' = Seller Central, 'VENDOR' = Vendor Central). A Vendor Central row is one listing: its vendorProductIdentifier (the identifier Amazon shows in Vendor Central) in one marketplace under one vendorCode; the same ASIN under two vendor codes is two rows. Its sku is the product SKU of the ASIN, as in the app's Copilot and Cockpit (the vendor's product code, or the ASIN when there is none), shared by the listings of that ASIN; skus filters on it. Vendor Central does not report five of the checks: not buyable, buy box lost, hijacker, price undercut and Incomplete never flag a Vendor Central row (Amazon is the seller: no offers block, offers is null, isFbm is null, status is Active or Inactive only).

Input Schema

NameRequiredDescriptionDefault
skusNo
sortNo'sales' (default) = biggest sellers first; 'severity' = worst alert band first.
tagsNo"Your Filters" tag IDS from list_tags (manual custom tags or predefined segmentations). A tag NAME is rejected — resolve it with list_tags first.
asinsNo
bandsNoAlert bands to keep: 0 cash-loss · 1 degraded · 2 watch · 3 none.
limitNoMax rows (1–1000, default 50).
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.
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.
channelsNoSelling channels to read: 'SELLER' = Seller Central (3P) listings, 'VENDOR' = Vendor Central (1P) listings, both = one list. Omit = SELLER whenever the accounts of the call include a Seller Central account, else VENDOR.
problemsNoKeep only listings failing ANY of these per-issue checks (OR union).
statusesNoMerchant-listing statuses to include. Omit = all statuses (the app defaults to ['Active']).
parentAsinsNoFamily keys — coalesce(parent_asin, asin), the cockpit parent-ASIN grain.
marketplacesNoRestrict to these marketplace IDs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only carry readOnlyHint=true, so the description carries the rest — and it does: channel defaulting rules, empty-list-not-error behavior, Vendor Central rows lacking five checks, and the non-obvious flag semantics (a buyable listing is never is_suppressed; Amazon's LISTING_SUPPRESSED notice counts as is_quality_issue). It also discloses the catalog-recapture gate (contentFetchedAt=null) and the keywordsScanned=false trap where NULL means 'not looked at', not 'none written'.

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?

Purpose is front-loaded before the field inventory, which is good, but the body is a single ~450-word block with nested parentheticals and some duplication of the `channels` and `bands` schema descriptions. The field-by-field row inventory is largely a substitute for the missing output schema, so it earns its place, but the packaging is denser than necessary.

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?

With 14 parameters, no output schema, and only one annotation, this description does the heavy lifting: it enumerates the returned row shape (status, issue flags, alert_band, buy-box block, content block), explains the channel-dependent shape differences, and warns about NULL semantics. An agent has enough to call it correctly and interpret results without additional context.

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 86%, so baseline is 3, and the description goes beyond it on the parameters that matter most: the omit-vs-pass semantics of `channels` (including the vendor-only scope case), what `skus` filters against for Vendor Central rows, and the effect of sort='severity'. A few parameters (tags, limit/offset, reason, marketplaces) are only covered by their schema text.

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 and scope: 'Current listing-health STATE per SKU', anchored to the app's Listing Health page so the agent knows exactly which entity is returned. It immediately draws the boundary against the sibling family of metrics tools by declaring 'Point-in-time entity state (NOT a metrics/date-range query — no from/to)'.

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?

Explicitly enumerates the questions it answers (which listings are removed/suppressed/not buyable, what to fix first, who is losing the buy box, content audits), and states the negative case (not a date-range metrics query). It does not name the sibling tool (e.g. query_metrics) the agent should use instead for time-series questions, so routing relies on inference.

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.