Skip to main content
Glama

Nova Amazon MCP Server

query_inbound_shipments

Read-only

FBA INBOUND SHIPMENTS — the app's Inventory › Inbound shipments panel, the same service the page calls (POST /v2/shipments): every shipment of the last 18 months at its CURRENT state, one record per shipment with its SKU lines (quantity shipped and received per SKU). Answers: what is on its way to Amazon, what Amazon has received so far, which closed shipments came up short (the reconciliation list), which SKU or ASIN has units in transit. category is the panel's own split: planned (WORKING / READY_TO_SHIP — units still with the seller, NOT inbound yet), in_progress (SHIPPED / IN_TRANSIT / DELIVERED / CHECKED_IN / RECEIVING with units still to receive), closed_incomplete (CLOSED and received < shipped), closed_complete (CLOSED and received >= shipped — Amazon sometimes receives more than declared). With sku or asin the category is judged on THAT product's lines, not on the whole shipment. ⚠️ Three things Amazon does not give, so neither does this tool: NO DATES (the inbound API exposes no shipped-at / received-at; fetchedAt is when Nova last read the shipment, nightly at 01:30 UTC, never a business date — within a category rows come in lifecycle order, and by missing units for closed_incomplete); marketplaceId is the marketplace Nova asked Amazon for, not where the shipment lives (the API ignores it) — read stockLocation / fcCountry, derived from the destination FC code; NO SHIPMENT COST anywhere (the inbound fees are query_metrics' fee keys, per SKU and day). isFromAwd flags an AWD → FBA replenishment leaving Amazon's own warehouse, not the seller's. Not a metrics tool: no period, no aggregation — read the counts off the records, or ask query_inventory for totalFbaIncoming / inboundUnits per SKU. SUMMARY (summary=true, 2026-10-22): the counters behind the Inventory page's « N shipments » pill, per product × stock location (POST /v2/shipments/summary), for the skus and / or asins given (a SKU on its own lines, an ASIN over all its SKUs), in stockLocation or in every location: openCount (shipments on their way: they left the seller and units are still to receive), awdCount (of them, the AWD → FBA replenishments), plannedCount (WORKING / READY_TO_SHIP, nothing left yet), incompleteCount (CLOSED with fewer units received than shipped), inboundUnits (the product's units still expected on the open ones) and missingUnits (its units never received on the closed ones); a product × location with none of these has no entry. At most 400 product × location pairs a call. On the list, dateFrom / dateTo bound fetchedAt and sortBy / sortOrder rank the shipments by one of the panel's columns.

Input Schema

NameRequiredDescriptionDefault
skuNoOnly shipments carrying this SKU; the category is judged on its lines.
asinNoOnly shipments carrying this ASIN; the category is judged on its lines.
skusNoWith summary=true: the SKUs to count, each on its own lines.
asinsNoWith summary=true: the ASINs to count, over all their SKUs.
limitNo
dateToNoKeep the shipments Nova last read (fetchedAt) on or before this day, the whole day (YYYY-MM-DD, UTC).
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.
sortByNoRank the shipments by this column of the panel instead of each category's own order (lifecycle; missing units first for closed_incomplete).
summaryNotrue = the per product × stock location counters of the page's shipment pill (SUMMARY above) instead of the shipments: needs `skus` and / or `asins`; `stockLocation` keeps one location (a stock region such as 'EU_FBA' is read as its location), omit it for every location.
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.
categoryNoThe panel's bucket: planned | in_progress (on the way) | closed_incomplete | closed_complete. Omit for every tracked shipment.
dateFromNoKeep the shipments Nova last read (fetchedAt) on or after this day (YYYY-MM-DD, UTC). fetchedAt is never a business date.
statusesNoAmazon statuses to keep (WORKING, READY_TO_SHIP, SHIPPED, IN_TRANSIT, DELIVERED, CHECKED_IN, RECEIVING, CLOSED). Prefer `category`.
sortOrderNoWith sortBy: desc (default) = highest first; asc = lowest first.
searchTextNoFree text over the shipment id, its name and the destination FC code.
shipmentIdNoOne FBA shipment id (FBA…).
stockLocationNoDestination stock pool, from the FC code: USA, Canada, Mexico, Brazil, UK, Pan-EU, India, Japan, Australia, UAE, Singapore, Egypt. With summary=true, omit it to count every location.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With only readOnlyHint=true in annotations, the description carries the burden and delivers: it discloses that no dates exist (fetchedAt is a nightly read at 01:30 UTC, never a business date), that marketplaceId is ignored by the API and destination must be read from stockLocation/fcCountry, that no shipment cost is exposed, and what isFromAwd flags. It also states the 400 product×location pair cap for summary calls.

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-loaded with the resource and scope, then caveats, then the summary mode — a sensible order. It is dense and re-explains fetchedAt in prose that the schema also covers, plus heavy ALL-CAPS and emoji usage, but nearly every sentence carries a distinct caveat rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter tool with no output schema, it explains the record shape (one per shipment with SKU lines including shipped/received quantities) and details the summary counters, which compensates for the missing output schema. Remaining gaps are minor, such as the exact response envelope and pagination behavior beyond offset/limit.

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 94%, so much is documented, but the description adds real meaning the schema lacks: the WORKING/READY_TO_SHIP versus SHIPPED/IN_TRANSIT mapping behind each category, and the nuance that with sku/asin the category is judged on that product's lines only. This is value beyond the schema's own wording, though some caveats (fetchedAt, stockLocation) are repeated from schema descriptions.

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+scope: 'FBA INBOUND SHIPMENTS — the app's Inventory › Inbound shipments panel... every shipment of the last 18 months at its CURRENT state, one record per shipment with its SKU lines.' It also explicitly distinguishes itself from siblings: 'Not a metrics tool... ask query_inventory for totalFbaIncoming / inboundUnits per SKU.' An agent can identify this tool versus query_metrics and query_inventory without opening any 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?

States when to use it ('what is on its way to Amazon, what Amazon has received so far, which closed shipments came up short') and when not to (metrics/aggregation belong elsewhere). It also documents a second mode (summary=true) and its trigger conditions, plus the alternative of query_inventory for totals.

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.