Skip to main content
Glama
nubiia-dev
by nubiia-dev

update_product_stock

Adjust a product's stock quantity in Holded by applying a positive or negative delta to a required warehouse, optionally targeting a variant and adding an audit note.

Instructions

Update stock quantity for a product (Holded API v2). BREAKING CHANGE from v1: warehouse_id is now required; stock_variation replaces units; optional variant_id and description added.

Input Schema

NameRequiredDescriptionDefault
productIdYesProduct ID
variant_idNoVariant ID to target a specific product variant (optional)
descriptionNoAudit note describing the stock adjustment (optional)
warehouse_idYesWarehouse ID (required in v2 — v2 rejects stock updates without it)
stock_variationYesStock delta (positive to add, negative to subtract). Replaces v1 `units`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.0.3
    • addedInput schema / properties / description
      Added value: +{
      +  "description": "Audit note describing the stock adjustment (optional)",
      +  "type": "string"
      +}
    • addedInput schema / properties / stock_variation
      Added value: +{
      +  "description": "Stock delta (positive to add, negative to subtract). Replaces v1 `units`.",
      +  "type": "number"
      +}
    • removedInput schema / properties / units
      Removed value: -{
      -  "description": "Number of units to add or subtract",
      -  "type": "number"
      -}
    • addedInput schema / properties / variant_id
      Added value: +{
      +  "description": "Variant ID to target a specific product variant (optional)",
      +  "type": "string"
      +}
    • removedInput schema / properties / warehouseId
      Removed value: -{
      -  "description": "Warehouse ID (optional)",
      -  "type": "string"
      -}
    • addedInput schema / properties / warehouse_id
      Added value: +{
      +  "description": "Warehouse ID (required in v2 — v2 rejects stock updates without it)",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "productId",
      -  "units"
      -]New value: +[
      +  "productId",
      +  "warehouse_id",
      +  "stock_variation"
      +]
  2. First observedv1.6.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that warehouse_id is mandatory and that v2 rejects calls without it, plus that the operation is a delta rather than an absolute set — but is silent on permissions, whether negative resulting stock is allowed, and the response shape.

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?

A single dense sentence with the core action front-loaded, followed by the migration caveat. Efficient, though the BREAKING CHANGE framing is more changelog than invocation guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation with zero annotation coverage and no output schema, the definition covers parameter shape adequately but omits the safety and side-effect context an agent needs — permission requirements, whether other warehouse quantities are affected, and what success returns.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters including the delta semantics of stock_variation and the audit-note purpose of description. The description mostly restates that schema content (variant_id/description optional, warehouse_id required), adding only the v1→v2 naming lineage.

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?

States a specific verb and resource: 'Update stock quantity for a product', which clearly separates it from the generic update_product sibling. It does not explicitly name alternatives such as update_product or the warehouse-stock reads, so it stops short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance given is version-migration detail (v1 vs v2), not when to use this tool versus siblings like update_product or when a stock adjustment is the right operation. No preconditions, no exclusions, no alternative routing.

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

Deploy Server

Other Tools