Skip to main content
Glama

Nova Amazon MCP Server

by io.novadata
OverviewDiscussionsAdmin

import_supply_chain

Import the PRODUCT table of the Supply chain page of ONE account — the same lines as the page's file (2026-10-22): one line per product × warehouse, carrying at most one supplier order (N open orders = N lines, the count and the six numbers repeated): the count at the warehouse / 3PL with its date, an order (units, expected date, PO reference, status), the case pack, the target stock at Amazon and at the warehouse, the transit to Amazon and to the warehouse, the production lead time. The payload changes the lines it names and NOTHING else: a field you omit keeps what is stored, null clears it (a count becomes unknown, an override is removed and the warehouse's number shows again), an order closes with status 'received' / 'cancelled' on its reference; the six numbers are the product's (its 'ALL' line), the same in every warehouse. The count's location and note are not here. On a line straight from the factory (get_supply_chain_products: warehouse.straightFromFactory) there is no warehouse: the count, the transit to the warehouse and the target there are not applied (a null there clears nothing) and the preview returns a notice for the row; put the whole trip, factory to sellable at Amazon, in leadTimeTransitDays. TWO-STEP, never skip the preview: call WITHOUT commit; the server validates (ASINs against the catalog, regions or warehouse names, ranges, dates) and returns per-row warnings, a per-warehouse diff (added lines with their values, changed lines before → after, removed, the warehouse's totals once written) and a confirmationToken; show them to the user and only after explicit approval call again with the SAME account/rows plus commit:true and the token. Up to 2000 rows per call. Requires the OAuth connection and the OWNER role.

Input Schema

NameRequiredDescriptionDefault
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. Changed2 schema fields changed
    • changedInput schema / properties / rows / items / properties / region / description
      Previous value: -"The warehouse's stock region as get_supply_chain_setup lists them ('USA', 'EU_FBA', 'UK', 'Canada'…; 'US', 'EU', 'GB' are accepted), or 'ALL' for the six numbers alone. Give either region or warehouse."New value: +"The warehouse's stock region as get_setup domain=supply_chain lists them ('USA', 'EU_FBA', 'UK', 'Canada'…; 'US', 'EU', 'GB' are accepted), or 'ALL' for the six numbers alone. Give either region or warehouse."
    • changedInput schema / properties / rows / items / properties / warehouse / description
      Previous value: -"The warehouse as get_supply_chain_setup names it (\"UNIS, Buena Park\", or \"UNIS\"): resolved to its region."New value: +"The warehouse as get_setup domain=supply_chain names it (\"UNIS, Buena Park\", or \"UNIS\"): resolved to its region."
  2. 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=false in annotations, the description carries the behavioral burden and does so thoroughly: it explains merge semantics (omitted keeps, null clears), order closure via status, straight-from-factory special handling, preview validation/diff output, confirmation-token requirements, row limits, and OWNER/OAuth prerequisites.

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 critical two-step safety flow are front-loaded, and nearly every sentence adds operational value for a complex import. However, the description is a very dense single block, making it harder to scan than it could be.

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?

There is no output schema, but the description explains what the preview returns (warnings, per-warehouse diff, totals, confirmationToken), the write behavior, the row cap, and the authorization requirements. Given the tool's complexity, this is complete enough for correct invocation.

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 80%, but the description adds significant cross-parameter meaning: the row identity model, how N orders map to N lines, how the six product-level numbers interact with warehouse lines, and how null versus omitted behaves for counts and lead-time fields.

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 states a specific verb and resource: import the PRODUCT table of the Supply chain page for one account. It further defines the row model (one line per product × warehouse, at most one supplier order) and notes what is not included, making the tool distinguishable from sibling import tools.

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?

It gives clear usage conditions: call without commit first, validate/diff, get explicit approval, then call again with the same payload plus commit:true and the token. It also states limits and prerequisites. It references get_supply_chain_products for straight-from-factory detection but does not explicitly name alternatives for other supply-chain import scenarios.

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