Move an asset to a specified location in Shelf, with optional quantity input for quantity-tracked assets. Use it to update asset location records and manage inventory movement.
Move an asset to a location. For quantity-tracked assets, optionally pass a quantity.
| Name | Required | Description | Default |
|---|---|---|---|
| orgId | No | Workspace/organization ID. Defaults to SHELF_ORG_ID or your current workspace. | |
| assetId | Yes | ||
| quantity | No | ||
| locationId | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, consistent with the 'Move' verb, so safety is covered. The description adds the conditional quantity nuance but says nothing about whether an existing placement is overwritten, permission requirements, or reversibility. With annotations carrying the safety profile, this is adequate but thin.
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?
Two tightly written sentences with the primary action front-loaded and the conditional detail second. No filler, no repetition of the name or annotations.
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?
There is no output schema, and for a mutation the description does not address what a successful move returns, how it interacts with existing placements, or cross-model context (e.g., does assetId accept a code vs an ID). It is minimally complete given annotations cover the safety signals, but leaves notable gaps.
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 only 25% (only orgId is documented in-schema), so the description must compensate. It usefully clarifies quantity semantics for quantity-tracked assets, but assetId and locationId carry no explanation in either place, leaving half the parameters unelaborated.
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?
Clear verb+resource+destination: 'Move an asset to a location' tells an agent exactly the operation performed. The singular 'an asset' implicitly distinguishes it from the bulk sibling shelf_bulk_update_location, but the description never names or contrasts that sibling explicitly.
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 clause 'For quantity-tracked assets, optionally pass a quantity' gives real conditional usage guidance about when to supply a parameter. However, it offers no routing against near-neighbors like shelf_bulk_update_location or shelf_adjust_quantity, leaving alternative selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.