Skip to main content
Glama

Nova Amazon MCP Server

by io.novadata
OverviewDiscussionsAdmin

set_stock_defaults

Set ONE account's numbers of the TOP table of the Supply chain page — the warehouse & 3PL setup: per warehouse (its stock region, or its name as get_setup domain=supply_chain lists it) the transit to Amazon, the target stock at Amazon, the target stock at the warehouse and the transit from the factory; per account (region 'ALL') the production lead time; and the factory lines (goods straight from a country to a territory). These are ranks 3 and 4 of the ladder, above the fleet default (rank 5, Nova's number, the page's gold figure) and below the product's own lines (import_supply_chain): a value set here reaches every product without its own number. Fields you omit keep their current value, null clears one; when a line's numbers end up blank its row is deleted. Give ONE region at the top level (the form of before 2026-10-22), or rows (several regions or warehouses at once) and / or factoryLines. TWO-STEP: call WITHOUT commit to preview current → new per parameter, show the user, then commit with the confirmationToken. Requires the OAuth connection and the OWNER role.

Input Schema

NameRequiredDescriptionDefault
rowsNoSeveral lines of the top table at once: one per region or warehouse, with the fields to change.
commitNoOmit/false = preview (no write). true = write; requires the confirmationToken from the preview.
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.
regionNoA stock region as get_setup domain=stock lists them ('USA', 'EU_FBA', 'UK', 'Canada'…; 'US', 'EU', 'GB' are accepted) or 'ALL' (every region without its own row).
accountYesThe seller account (seller_partner_id, or an unambiguous account name).
factoryLinesNoThe factory lines of the top table: one per (country, territory), with the fields to change.
targetDaysAmazonNoDays of cover to hold at Amazon (FBA + AWD). Omit = unchanged, null = clear.
confirmationTokenNoThe token the preview returned.
targetDaysExternalNoDays of cover to hold at the external location; 0 for sellers shipping straight to FBA. Omit = unchanged, null = clear.
leadTimeTransitDaysNoDays in transit to the external location or to Amazon. Omit = unchanged, null = clear.
leadTimeProductionDaysNoDays from the purchase order to the goods leaving the factory. Omit = unchanged, null = clear.
leadTimeToWarehouseDaysNoDays from the factory to the warehouse / 3PL; 0 when the goods ship straight to Amazon. Omit = unchanged, null = clear.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / factoryLines / items / properties / region / description
      Previous value: -"A stock region as get_stock_setup lists them ('USA', 'EU_FBA', 'UK', 'Canada'…; 'US', 'EU', 'GB' are accepted). Never 'ALL': the units sit in one place."New value: +"A stock region as get_setup domain=stock lists them ('USA', 'EU_FBA', 'UK', 'Canada'…; 'US', 'EU', 'GB' are accepted). Never 'ALL': the units sit in one place."
    • changedInput schema / properties / region / description
      Previous value: -"A stock region as get_stock_setup lists them ('USA', 'EU_FBA', 'UK', 'Canada'…; 'US', 'EU', 'GB' are accepted) or 'ALL' (every region without its own row)."New value: +"A stock region as get_setup domain=stock lists them ('USA', 'EU_FBA', 'UK', 'Canada'…; 'US', 'EU', 'GB' are accepted) or 'ALL' (every region without its own row)."
    • changedInput schema / properties / rows / items / properties / warehouse / description
      Previous value: -"The warehouse as get_supply_chain_setup names it: its region takes the numbers."New value: +"The warehouse as get_setup domain=supply_chain names it: its region takes the numbers."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the lone readOnlyHint=false annotation, the description discloses the merge semantics ('omit = unchanged, null clears'), a destructive side effect ('when a line's numbers end up blank its row is deleted'), the preview/commit protocol with confirmationToken, and the auth/role requirement. These are exactly the behavioral traits an agent cannot infer from the annotation.

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?

The purpose and scope are front-loaded and every clause carries operational meaning, but it is a single dense, em-dash-laden block with decorative asides ('Nova's number, the page's gold figure') that slow parsing. Justified in length by the tool's complexity, slightly improvable in structure.

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 12-parameter mutation tool with no output schema, the description covers the input-shape alternatives, merge/clear/delete semantics, the confirmation flow, and auth requirements. An agent has everything needed to call it correctly and safely without further documentation.

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?

With 100% schema description coverage the baseline is 3, and the description earns an extra point by explaining the conceptual model behind the params: region 'ALL' vs per-warehouse rows, what each numeric field controls in the ladder, and how factoryLines differ (never 'ALL'). It stops short of adding format details beyond the schema, but the added meaning is real.

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?

The description opens with a specific verb and resource — 'Set ONE account's numbers of the TOP table of the Supply chain page' — and immediately scopes it to the warehouse/3PL setup. It explicitly positions the tool against siblings by naming import_supply_chain (product-level lines) and get_setup (to enumerate domain/warehouse values), so an agent can distinguish it 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?

It states the precedence rule ('a value set here reaches every product without its own number'), the alternative that overrides it (import_supply_chain), the two alternative input shapes (single region vs rows/factoryLines), the mandatory two-step preview-then-commit flow, and the prerequisites (OAuth connection, OWNER role). That is close to a complete when/when-not/alternatives guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Nova Amazon MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources