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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description's job is to add transformation specifics. It does so in detail: it names the exact whitespace characters handled (spaces, tabs, non-breaking spaces), states that each line is trimmed, preserves line breaks, and exposes optional blank-line removal. The source URL adds provenance, and nothing in the description contradicts the annotations.

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 three short sentences plus a source URL; the core behavior is front-loaded in the first sentence, followed by the optional flag and the key caveat. Every sentence carries information an agent needs, and there is no redundant restatement of the title or 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 only two parameters, rich annotations, and an output schema present, the description covers all relevant decisions: what gets normalized, that line breaks survive, and how blank lines are handled. The specification of tabs and non-breaking spaces handles likely edge cases, making the tool callable without further investigation.

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 100%, so the schema already documents both 'text' and 'removeBlankLines' with defaults. The description explains the effect of removeBlankLines ('Can optionally also remove blank lines') and implies the text parameter via 'text', but does not add meaningful syntax, edge-case, or format details beyond the schema. This is the baseline-3 case.

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 verb and resource ('Tidy up spacing in text') and precisely enumerates the transformation: collapse runs of spaces, tabs, and non-breaking spaces, trim each line, and optionally remove blank lines. It also explicitly states 'Line breaks between lines are kept', which distinguishes this tool from nearest siblings like hopi_remove_line_breaks and hopi_remove_duplicate_lines without requiring the agent to infer.

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 behavior described establishes clear usage context: use when whitespace within text needs normalizing while line structure is preserved. The explicit caveat that line breaks are kept and the optional removeBlankLines flag imply when not to use line-break-removal siblings, though no sibling is named and no explicit when/when-not statement is given.

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