Show one packing list

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

No annotations are present, so the description carries the responsibility for behavioral disclosure. It adds a genuinely useful, non-obvious trait – 'nothing here is stored; it is computed' – which tells the agent the output is derived on the fly and that the call does not alter state. It also clarifies that readiness and shortfall are computed; it stops short of explicitly labeling the operation read-only or describing error behavior, but for a 'plain show' tool this is strong discretion provided.

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?

The description is a tight two-sentence structure: the first sentence front-loads the exact contents of the result, and the second delivers the essential computed-storage distinction. Every clause adds new information and there is no redundancy with the title or the schema.

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?

With no output schema or annotations to fall back on, the description does all work of telling an agent what it will see. It does list major content areas, but it omits the output format, error conditions (e.g., unknown packing list id), and any explanation of denominators for the computed fields. Given the tool's moderate complexity and the lack of supplementary structured metadata, the description is passable 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 coverage is 100% and both distinct parameters have detailed descriptions, so the schema already explains divisor units and the packing_list id/order reference formats. The description adds little about parameters individually; the mention of 'derived weights' vaguely ties to divisor but is not enough to raise the score above the schema baseline. The schema is doing the heavy lifting, so a middle score is correct.

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 clear action ('show') on a concrete resource ('one packing list') and enumerates exactly what is returned: cartons with contents and derived weights, ordered lines, shortfall, readiness with reasons, and status history. This differentiates it from siblings like packing_list_list (which covers multiple lists) and the individual tools (packing_shortfall, packing_list_status, carton_report) by presenting the full aggregate view.

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 provides no explicit guidance on when to choose this tool over siblings. It does not name alternatives, say what conditions warrant the full view, or give exclusions (e.g., 'for the list index use packing_list_list'). The only context hint is in the parameter schema about the order reference, but that concerns input format, not tool selection.

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