Skip to main content
Glama

Nova Amazon MCP Server

by io.novadata
OverviewDiscussionsAdmin

import_stock_params

DEPRECATED (2026-10-22): use import_supply_chain, the Supply chain table as one line per product and warehouse, which changes only the lines it names; this tool stays for callers that still use it. Import the REORDER PARAMETERS of ONE account — per product × stock region (or 'ALL'): production lead time, transit lead time to Amazon, lead time from the factory to the warehouse (leadTimeToWarehouseDays), target days of cover at Amazon and at the external location, case pack. A product needs all five to RESOLVE (its own row → its 'ALL' row → the account defaults) before query_inventory recommends anything; a blank field resolves to the next rank, so set the account-wide values with set_stock_defaults and import here only the exceptions. A seller shipping straight from the factory to FBA has an external target of 0 and a to-warehouse lead time of 0, not blank. TWO-STEP, never skip the preview: call WITHOUT commit; the server validates (ASINs against the account's stocked products, regions, ranges) and returns per-row warnings, an ASIN-grain diff per (account, region) and a confirmationToken; show them to the user and only after explicit approval call again with the SAME account/mode/rows plus commit:true and the token. Mode 'merge' (default) touches only the (ASIN, region) rows you send, FIELD by field — a field you omit keeps its current value, null clears it; 'replace' restates every (account, region) present in rows whole — a product absent from rows loses its row there, an omitted field is blank. A row with nothing on it is refused (an import never clears a row). Up to 2000 rows per call. Requires the OAuth connection and the OWNER role.

Input Schema

NameRequiredDescriptionDefault
modeNo'merge' (default): only the sent rows change. 'replace': restate each (account, region) present in rows.
rowsYes
commitNoOmit/false = preview (validate + diff, 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.
accountYesThe seller account (seller_partner_id, or an unambiguous account name). One account per call.
confirmationTokenNoThe token the preview returned — proves the user saw exactly this payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / rows / 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) 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)."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations carry only readOnlyHint=false, so the description carries the behavioral burden and does: server-side validation scope (ASINs against stocked products, regions, ranges), returned per-row warnings and ASIN-grain diff, confirmationToken requirement, the 2000-row cap, refusal of empty rows, and the OAuth + OWNER role prerequisite. Merge/replace semantics are spelled out field by field, including that omitted keeps vs blanks and that null clears.

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 deprecation and successor, then the core operation; every clause is dense with operative content. It loses a point for restating material the schema already documents at length — merge/replace behavior appears in both the prose and the mode/field descriptions, and 'up to 2000 rows' duplicates maxItems.

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 two-step, role-gated, 2000-row batch mutation with no output schema, the description supplies everything needed to call it correctly: prerequisites, preview/commit flow, token handling, validation feedback shape, row and field semantics, and the fallback resolution model. Nothing material is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 83%, but the description adds meaning the schema cannot: the three-rank resolution hierarchy (own row → 'ALL' row → account defaults) that explains why a blank field is legitimate, and the merge-vs-replace consequence per field. It also documents the ALL pseudo-region and the deprecation path, which no parameter doc covers.

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 the deprecation and names the successor (import_supply_chain), then states a precise verb+resource: import the reorder parameters of one account, per product × stock region. An agent can tell this apart from set_stock_defaults and import_supply_chain 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?

Gives explicit routing: set account-wide values with set_stock_defaults and import only exceptions here; use import_supply_chain for the new table. Adds hard procedural rules — never skip the preview, call again with commit:true plus the token only after user approval — plus the factory-to-FBA edge case where external target and to-warehouse lead time are 0, not blank.

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