Skip to main content
Glama

grocy_stock_transfer

Transfer a specified product amount between stock locations using product ID or barcode. Omit confirm for a dry-run preview before executing.

Instructions

Transfer amount of a product between locations. POST transfer, by product_id or barcode. Omit confirm for a dry-run.

Input Schema

NameRequiredDescriptionDefault
amountYes
barcodeNoProduct barcode. Provide this or product_id.
confirmNoSet to the boolean true to execute the write. Omit this field for a dry-run preview. false and the string true are rejected.
product_idNoProduct id. Provide this or barcode.
location_id_toYes
stock_entry_idNo
location_id_fromYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

The annotations already declare a non-read-only, non-idempotent write operation, and the description adds useful behavior: POST transfer and dry-run preview by omitting confirm. It still does not describe side effects on source and destination stock beyond the obvious transfer.

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?

Three short sentences, front-loaded with the core action, then the product lookup method, then the dry-run behavior. There is no wasted wording.

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?

The definition is adequate for a moderate-complexity mutation tool with no output schema, but it omits stock_entry_id and does not explain the required location semantics or the effect on source and destination stock. The schema covers confirm in detail, which partially offsets the gaps.

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 only 43%, so the description needs to compensate. It clarifies the product_id-or-barcode alternative and the confirm dry-run behavior, but it leaves amount, location_id_from, location_id_to, and especially stock_entry_id without added meaning.

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?

The description states a specific verb and resource: transfer an amount of a product between locations. It is clearly a stock movement operation, distinct from siblings like grocy_stock_add or grocy_stock_consume, but it does not explicitly name or route against those alternatives.

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

Usage Guidelines3/5

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

It implies when to use the tool by saying it transfers between locations and notes that omitting confirm produces a dry-run. However, it does not explain when to choose this over related stock tools or when not to use it.

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