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

Annotations already indicate read-only and idempotent behavior. The description adds substantial behavioral context: deterministic calculation, stacking behavior (stackable=true with stack_height 2 or 3 divides floor footprint), fits logic based on vehicle length, rate limiting with 429 retry guidance, and response envelope details. These are not present in annotations and significantly help the agent anticipate side effects and error handling.

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 rich but tightly organized: core definition, usage requirements, behavior details, rate limits, return structure, and related tools. Every sentence contributes value, and it front-loads the most critical information. Though longer than typical, it remains efficient and scannable.

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?

Given the tool's complexity (9 parameters, output schema, rate limits), the description is exceptionally complete. It covers preconditions, error behavior, response fields, and sibling relationships. The existence of an output schema does not weaken the description, which still clarifies the semantics of returned values like utilisation_percent and fits.

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?

Though the schema covers 100% of parameters, the description adds relational and conditional meaning that the schema cannot express: the mutual exclusivity of pallet vs custom dimensions, the effect of stackable/stack_height on results, and the dependency of weight_kg on payload validation. This elevates parameter understanding beyond individual attribute descriptions.

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 opens with a specific, action-oriented statement: 'Calculate loading metres (LDM) for European road freight — how much trailer length a pallet load occupies.' It defines LDM and clearly distinguishes this tool from sibling calculators by focusing on linear trailer length for pallet loads, with references to related tools that cover different use cases (e.g., pallet_fitting_calculator, consignment_calculator).

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 explicitly states when to use the tool and provides alternatives via the 'Related' section. It also provides critical usage constraints: 'Provide a pallet preset OR custom length_mm + width_mm — omitting both errors with a usage hint.' This goes beyond vague guidance and gives actionable selection criteria.

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