Skip to main content
Glama

Nova Amazon MCP Server

get_setup

Read-only

Start here for any seller input: the setup surface of ONE domain, as the header of its Data Inputs page shows it. Read it before an import (target format, valid codes, import steps) and again after, to verify. domain: 'cogs' (cost of goods): default currency, each region's catalog SKU count and how many SOLD SKUs are missing COGS (profit overstated there), region inheritance policies, the valid region codes. soldSkusMissingCogs drops after an import. Covers Seller Central (3P) and Vendor Central (1P) accounts alike; when the scope holds a 1P account, vendorCentral lists it with the rules of a 1P cost (the vendor's OWN product cost, never Amazon's Shipped COGS; period-based only). Next: get_cogs_worksheet, import_cogs. 'fbm' (merchant-fulfilled shipping cost): per account, WHERE the seller ships (delivery countries with their share of FBM sales over 24 months, grouped in containers — Europe, North America, Far East — each led by its biggest destination), which countries have a shipping rate ('priced'), which read their container's rate ('container'), which fall on the rest-of-world rate ('row'), and which have NOTHING ('required' — the P&L cannot price those orders), plus packing/picking handling rates, per-product overrides and legacy rows; the zone/kind/rule vocabulary and how the P&L resolves a cost. Next: get_fbm_worksheet, import_fbm_zone_rates, import_fbm_costs. 'stock' (replenishment: reorder quantities, lead times, external / 3PL stock, supplier orders): per account, the stock regions it holds stock in, how many products are fully parameterised (the five reorder parameters — production lead time, transit from the factory to the warehouse, transit lead time to Amazon, target days of cover at Amazon and at the external location — resolved per product × region: product row → product 'ALL' row → seller default per region → seller default 'ALL' → fleet default (Nova's number for the warehouse, read from the seller's shipments and never typed; the Warehouse & 3PL page shows it in gold); a product whose five do not all resolve gets NO recommendation), the seller defaults, how many products carry an external (own warehouse / 3PL) count, how many supplier orders are open, and the last imports. Read it before query_inventory with includeReorder=true, to know whether the recommendations rest on entered parameters. Next: get_stock_worksheet, import_stock_params, import_external_stock, import_supplier_orders. 'supply_chain' (the TOP table of the Supply chain page): per account the production lead time; per warehouse its name and city, the territories it ships to with their transit to Amazon and target stock at Amazon, the target stock held at the warehouse and the transit from the factory, each number with its source ('yours' = the seller typed it, 'fleet default' = Nova's proposal from the fleet's shipments, the page's gold figure; beside a number the seller typed, fleetDefault is the proposal it replaces), how many products it holds and how many have a count; and the factory lines (goods straight from a country to a territory). Per warehouse also: key, the departure point the warehouse is named after, as query_inventory's departurePoints[].key names it; departurePoints, its other departure points (name, city, country, sharePct of the units shipped into its territories, shipments, units, status alive or past, factory) and otherPoints, the smaller ones folded (count, shipments, units); shippedToAmazonL12M, what it sent to Amazon over twelve months (units, shipments, onTheWay counts, and lastShipment, the date of its last plan, read from the name Seller Central gives a plan by default: null as soon as a plan of the window carries no readable date, since a seller who renames its plans would otherwise read its last default-named plan, months old, as its last shipment; undatedShipments counts those renamed plans, still listed by Amazon); onTheWay, its shipments on their way to Amazon (id, name, Amazon's status, phase, destination, units, unitsReceived, skus, created: null on a renamed plan); awdSharePct, the share of its units sent to Amazon through AWD, in %; freight, how its transit from the factory was read (zone, factory country, averageLotUnits, toConfirm when no factory shipment was read). Per account remote: the territories Amazon serves from another territory's stock. evidenceSince: the first day of the shipments read. Nova reads the warehouses from the seller's shipments: they are never configured. Next: set_stock_defaults (writes these numbers), import_supply_chain (takes a warehouse's name on its lines), get_supply_chain_products (the product lines). 'vat': PER ACCOUNT and per VAT region (EU, UK, Mexico, and OutsideEU read-only…), whether AMAZON prices the tax (VCS — then the seller's categories never reach the P&L) or the seller's product category does, with the count of SOLD SKUs Nova has no VAT for (profit wrong there); the account's default category; the full category referential (code + name, incl. the Nova codes A_NOVA_ZERO / A_NOVA_STANDARD / A_NOVA_REDUCED); how the P&L resolves VAT. Read the account you import for — verdicts are never pooled across accounts. Next: get_vat_worksheet, import_vat_categories, set_vat_default_category.

Input Schema

NameRequiredDescriptionDefault
domainYesWhich seller input: 'cogs', 'fbm', 'stock' (replenishment parameters), 'supply_chain' (warehouses & 3PL) or 'vat'.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/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 real burden and does so richly — it discloses that warehouses are read from shipments and never configured, that lastShipment is null on renamed plans, that missing COGS/VAT means overstated profit, how the P&L resolves costs and VAT, and the parameter-resolution fallback chain for stock. This is exactly the kind of behavioral context annotations cannot provide.

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?

It is front-loaded with 'Start here for any seller input' and organized domain by domain, and most detail is genuinely interpretive. But it is a very long, semicolon-chained wall of text for a three-parameter tool, with some over-specified asides (the full lastShipment null rationale, the five-parameter resolution chain) that slow tool selection rather than enabling it.

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 no output schema, the description compensates by describing the return contents per domain in enough depth to reason about what the call yields. For a read-only setup tool covering five domains, nothing essential to correct invocation or interpretation is missing.

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 100%, so the baseline is 3; the description earns more by expanding each `domain` enum value into a concrete inventory of what will be returned (e.g., soldSkusMissingCogs for cogs, priced/container/row/required for fbm). It does not add anything about the `reason` parameter, and `accounts` scoping is only implied ('verdicts are never pooled across accounts'), keeping it from a 5.

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 states the resource (the setup state of ONE seller-input domain) and enumerates each domain's contents in detail, which lets an agent distinguish it from the worksheet/import siblings. The opening phrase 'setup surface ... as the header of its Data Inputs page shows it' is somewhat abstract, but the per-domain breakdown removes ambiguity.

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 sequencing is given: read before an import to learn target format/valid codes, read again after to verify; for stock, read before query_inventory with includeReorder=true; for VAT, read the specific account because verdicts are never pooled. Each domain also names the next tools (get_cogs_worksheet, import_cogs, etc.), so the agent knows the alternatives and when they apply.

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.