Skip to main content
Glama

stock_item_delete

DestructiveIdempotent

Soft-delete a stock item by id: sets is_active to 0 while its movements-ledger history stays intact. stock_item_adjust then refuses the id as NOT_FOUND and stops resolving it by name, so a later delivery under the same name creates a fresh item instead of reviving this one. stock_item_list and stock_item_read still return it with is_active: 0 — only the dashboard's stats header excludes it. Restore by running a normal update that sets is_active back to 1; there is no separate restore door.

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": {
      "id": "<id>"
    },
    "name": "stock_item_delete"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe stock item id to soft-delete (stock_item_list shows them).
nameNo
unitNo
notesNo
categoryNo
quantityNo
is_activeNo
expiry_dateNo
sell_price_centsNo
cost_per_unit_centsNo
low_stock_thresholdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

The description goes well beyond the annotations by detailing soft-delete semantics: movements-ledger history remains intact, stock_item_adjust treats the id as NOT_FOUND, list/read still return it with is_active: 0, and only the dashboard stats header excludes it. It also explains the restore mechanism, adding concrete lifecycle context that annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the core definition and then uses each sentence to add a specific behavioral consequence without redundancy. The density is justified by the operational complexity being explained.

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

Completeness4/5

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

The description thoroughly covers the core operation and side effects, and since there is no output schema, it appropriately explains how list/read still return the item. The main gap is that the ten non-required schema parameters remain unexplained, which could confuse an agent about whether to pass them.

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

Parameters2/5

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

Schema description coverage is only 9%; the description mentions id and tangentially is_active (for restore), but the nine other optional parameters (name, unit, quantity, etc.) are undocumented and it is unclear whether they are ignored, rejected, or relevant. With such low schema coverage, the description should compensate but does not.

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 (soft-delete) and resource (stock item) scoped by id, and distinguishes the tool from stock_item_adjust, stock_item_list, and stock_item_read by describing their post-deletion behavior. An agent can immediately tell what this tool does and how it differs from siblings.

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 clearly explains the consequence of using this tool and explicitly names the restore path via a normal update setting is_active to 1, plus how sibling tools behave after deletion. It stops short of an explicit 'use this when/when not' statement, but the operational context is strong.

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.

Resources