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

Annotations already mark the tool readOnly and idempotent. The description adds valuable behavioral context by disclosing the LCS algorithm and emphasizing that results are deterministic ('not guessed by a model'). This goes beyond the structured annotations without contradicting them.

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?

Two sentences, front-loaded with the primary outcome, then the use case and rationale. Every sentence contributes essential information with zero redundancy or filler.

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 simple two-string tool with full schema coverage, rich annotations, and an output schema, the description provides complete context: what it returns, how it computes it, and when to use it. No additional explanation of return values is needed given the output schema.

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%, with each parameter explicitly described as 'first (before) text' and 'second (after) text'. The description reinforces the directional comparison but adds little new parameter-level meaning beyond the schema already provides.

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 'Returns which lines were added and which were removed, with line numbers', clearly specifying the verb and output. The phrase 'computed with a longest-common-subsequence, not guessed by a model' and title 'line by line' differentiate it from sibling tools like diff_tables and from ad-hoc LLM comparison.

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?

Explicitly states when to use: 'Use to compare two versions of a config, a document, or any command output'. It also names the alternative to avoid: 'instead of asking an LLM to eyeball two blobs and hoping it notices', which gives both a positive use case and a clear avoid-this-approach.

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