Search stock moves by product, lot, state, and location filters to audit inventory movement history and diagnose stock discrepancies.
Search stock moves with product, lot, state and location filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | ||
| lot_id | No | ||
| product_id | No | ||
| to_location_id | No | ||
| from_location_id | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It only conveys the read-only nature of 'search' by implication and says nothing about pagination, state value formats, required permissions, or result behavior. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It is efficient and easy to parse, though its brevity comes at the cost of omitting useful behavioral and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six unannotated parameters and zero schema descriptions, this one-liner is incomplete. Even with an output schema available to describe returns, the agent still lacks parameter semantics, pagination details, and guidance on selecting this tool among over twenty siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and with six parameters the description must compensate. It adds only coarse categories ('product, lot, state and location filters') and does not explain the meaning or accepted values of product_id, lot_id, state, or location IDs, leaving the agent to infer too much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('stock moves'), and names the main filter dimensions (product, lot, state, location). This clearly conveys the tool's basic function, but it does not explicitly distinguish it from sibling search tools like find_non_done_moves or get_stock_move_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the general filtered search for stock moves, giving a clear basic context for when an agent would use it. However, it offers no explicit guidance about alternatives or exclusions, such as preferring find_non_done_moves for state-specific searches or get_stock_move_detail for a single move.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.