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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered and the description need not restate it. The description adds one useful behavioral note — that the distance and the shared topology are reported together, framing disagreement as a data result rather than an error. Beyond that it discloses nothing further about behavior, so with the lowered bar a 3 is appropriate.

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 tight sentences with the core operation front-loaded: distance and consensus come first. The second sentence is a conceptual remark about interpreting disagreement, which is defensible but leans slightly editorial rather than operational. Minimal waste overall.

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 an output schema present, the description need not explain return values, and it correctly leaves output semantics largely to structured fields. Annotations cover the safety profile and 100% schema coverage documents all parameters. For a 6-parameter tool with nested objects the description is adequate, though it could say more about the mismatch-refusal default that sharedTaxaOnly toggles.

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 mode, cutoff, trees, _files, _subject and sharedTaxaOnly are all fully documented in the schema itself. The description's mention of 'any number' of trees and 'same taxa' only loosely maps to the trees/sharedTaxaOnly parameters and adds no syntax or format detail. Baseline 3 when the schema does the heavy lifting.

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 (compare) and resource (trees) and pins down exactly what is computed: the Robinson-Foulds distance between two trees and the consensus of any number. This is far more precise than a generic 'compare' and lets an agent know the output. It does not, however, explicitly distinguish itself from overlapping siblings like discover_tree_incongruence or tree_statistics, so it falls short of a 5.

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?

'over the same taxa' states a prerequisite, and 'two of them, and the consensus of any number' implies the tool handles 2+ trees. But there is no explicit when-to-use guidance and no routing to alternatives such as discover_tree_incongruence or build_tree, leaving the agent to infer boundaries. Usage is implied rather than spelled out.

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