Skip to main content
Glama

set-variation-inventory

DestructiveIdempotent

Set the warehouse stock of ONE variation on a multi-variation listing, and queue the marketplace revise that shows it to buyers. This writes only that variation — sibling variations and the parent listing are untouched. It is the direct write behind the variations[].warehouseQuantity get-product-listings reports.

Address the variation by variationId (the variations[].id from get-product-listings with withVariations) or by its own sku — not the parent listing's SKU. A SKU matching more than one variation is refused rather than guessed; pass sellerId to resolve it.

ONLY for a variation with no catalog product behind it. If the variation has a productId, its stock belongs to that product: use patch-product instead, or Inventory Sync will overwrite this write.

The stock is saved immediately; the channel revise runs asynchronously, so re-read the listing to see the buyer-visible quantity change. With Inventory Control on the channel gets min(warehouseQuantity, max(upToQuantity, 1)), reported back as channelQuantity. Authenticated via bearer token.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "warehouseQuantity": "<warehouseQuantity>"
    },
    "name": "set-variation-inventory"
  }
}

Input Schema

NameRequiredDescriptionDefault
skuNoThe variation to write, by its own SKU (not the parent listing's)
sellerIdNoMarketplace account to resolve an ambiguous sku against
variationIdNoThe variation to write, by its id. Use this or sku.
warehouseQuantityYesThe on-hand stock to record for this variation

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructiveHint/idempotentHint annotations, the description discloses that the stock write is immediate while the channel revise is asynchronous, that the buyer-visible value is min(warehouseQuantity, max(upToQuantity, 1)) under Inventory Control, and that Inventory Sync can overwrite this write. These are exactly the operational traits an agent cannot infer from annotations alone.

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?

Well front-loaded: the write scope comes first, then addressing rules, then the exclusivity warning, then async semantics. Dense but nearly every sentence carries load; the trailing 'Authenticated via bearer token' is boilerplate that adds nothing for an agent already configured with auth.

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 destructive, open-world mutation with no output schema, the description covers addressing, eligibility preconditions, sibling alternatives, async timing, channel-quantity derivation, and overwrite risk. Nothing an agent needs to invoke it safely 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, but the description meaningfully extends it: variationId must be the variations[].id (not the parent id), sku must be the variation's own SKU, and sellerId exists specifically to disambiguate a SKU matching multiple variations — with the ambiguity refusal behavior stated.

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 opening sentence states a specific verb and resource — set warehouse stock for ONE variation — and scopes it against siblings by noting the parent listing and sibling variations are untouched. An agent can distinguish it from set-listing-inventory and patch-product 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?

Explicit when-not guidance: 'ONLY for a variation with no catalog product behind it. If the variation has a productId... use patch-product instead.' It also names get-product-listings with withVariations as the source of addressing identifiers, and explains the sellerId fallback for ambiguous SKUs.

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.