unpack_itemRemove one packed line from a packing list by its L01-style id and return the carton it came out of. The line is deleted, not zeroed, so the slip does not print an item nobody packed.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | The packed line id, e.g. L03, as shown by packing_list_show or carton_report | |
| packing_list | Yes | The packing list id, e.g. PL-2026-0001, or the order reference when only one list carries it |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the behavioral disclosure and covers it well: it explicitly states the line is deleted (not zeroed) and that the slip will not print an item nobody packed, which is the key disruptive trait. It stops short of addressing reversibility or required permissions, but the most safety-relevant behavior is exposed.
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 sentences with no wasted words: the first states the action, target, identifier style, and return value; the second explains the crucial delete-vs-zero distinction and its downstream effect. The most identifying information is front-loaded.
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 two-parameter tool with full schema coverage and no output schema, the description is largely sufficient: it says what is operated on, what is returned, and the important consequence for the shipping slip. Minor gaps are the unspecified format of the returned carton and lack of any error/state conditions, but these are not required for correct invocation.
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 coverage is 100%, and the parameter descriptions already give examples such as 'L03' and 'PL-2026-0001', so the baseline is 3. The description adds only the notion that the line corresponds to a carton from which it is removed, which is a minor enhancement over the schema.
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 opener uses a specific verb ('Remove') and a precise resource ('one packed line from a packing list by its L01-style id'), plus the return of the carton. This clearly distinguishes it from siblings such as packing_list_delete, pack_item, and carton_add, and from search/report tools.
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?
No sibling tool is named and no explicit when-not-to-use guidance is provided. The 'deleted, not zeroed' sentence strongly implies the intended scenario (correcting a mistaken pack), but an agent is left to infer the alternative paths (e.g., repacking with pack_item) rather than being directed to them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.