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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description's help. The description adds only that it returns a roll count and consumes room/roll/pattern inputs, which is modest extra context. It says nothing about how pattern repeat affects the result, which is the one genuinely behavioral detail worth disclosing.

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 four short, front-loaded sentences that lead with what is computed. It is efficiently sized, though the 'Inputs:' and 'Returns:' fragments largely restate what the schema and output schema already provide.

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?

An output schema exists, so return values need no explanation, and the list_bundles cross-reference helps orientation. However, the dangling 'pattern repeat' input and the unaddressed overlap with calculate_wallpaper_rolls leave the agent with open questions about 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%, so the baseline would be 3, but the description names an input — 'pattern repeat factor' — that does not exist anywhere in the schema (only height_m, perimeter_m, roll_width and roll_length are defined). This misleads the agent about the tool's expected arguments rather than adding meaning, so it scores below the schema-backed baseline.

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 specific verb and resource ('Compute wallpaper rolls needed for a room'), which is clear enough to distinguish it from generic calculators. However, it never differentiates itself from the near-identical sibling calculate_wallpaper_rolls, which an agent would otherwise confuse it with. Clear purpose, but sibling differentiation is absent.

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?

'Use for renovation budget' gives an implied context but no when/when-not logic and no alternatives. The pointer to list_bundles is a navigation aid rather than usage guidance, and it does not resolve the overlap with calculate_wallpaper_rolls.

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