pack_check

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

With no annotations, the description carries the full burden and does well: it discloses that `fits` permits reorientation via sorted-dimension comparison, defines each computed quantity, notes the DIM factor default and the max() rule for billable weight. It omits error/failure behavior and the unit of mass_g, but the computational semantics are unusually well 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?

Front-loads the core purpose in the first clause, then packs tightly-worded parameter and formula definitions with no filler. The formula block is dense but each line adds information that is unavailable elsewhere given the absent output 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?

For a pure-computation tool with no output schema and 0% parameter coverage, the description supplies both the input conventions and the exact return shape ({fits, void_fraction, dim_weight_kg, actual_mass_kg, billable_weight_kg, pass}), which is exactly what's needed to call and interpret it. Only usage routing and mass units are missing.

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%, so the description must compensate, and it does for three of four parameters: part_bbox_mm/carton_mm are declared as [l,w,h] in mm, and dim_factor is given a default of 5000 with 'metric DIM' semantics. Only mass_g's unit is left implicit (inferable from the returned actual_mass_kg).

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?

States a specific verb+resource pair: checking a part against a shipping carton and computing billable weight, which is distinct in scope from engineering siblings like fit_check or envelope_check. The 'shipping carton + billable weight' framing makes the logistics intent unmistakable, though it never explicitly names the sibling it complements or excludes.

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 explains what the tool computes but gives no when-to-use guidance, no prerequisites, and no routing against the many adjacent check tools (fit_check, envelope_check, interference_check). An agent must infer its applicability from the domain alone.

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