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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered and the description only needs to add statistical behavior. 'RETURNS: 两两比较 P 值' does signal the output is a pairwise P-value table, but the description never discloses the multiple-comparison correction method, which is the single most consequential behavioral detail for a Dunn implementation. Nothing 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 pipe-delimited, front-loaded structure (identity, USE WHEN, ALIASES, RETURNS) lets an agent parse intent in one pass with no rambling prose. The ALIASES segment is longer than strictly needed but serves discovery matching across Chinese and English phrasings. Nothing is redundant with the 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?

For a single-parameter, no-output-schema tool the definition is nearly sufficient: it says when to call it and what comes back. The gaps are the post-hoc adjustment method and preconditions (>=3 groups, adequate per-group n, ties handling) that determine whether results are trustworthy. Adequate but not complete for a statistics tool.

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?

There is only one parameter, nested, with 100% schema description coverage ('{组名: [数值...]}'), so the schema already tells the agent to pass a mapping of group name to numeric vector. The description adds no constraint on minimum group count, minimum sample size per group, or handling of missing values. Baseline 3 applies when the schema carries the parameter burden.

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?

Names a specific statistical procedure (Dunn post-hoc) and states its scope: pairwise comparisons after Kruskal-Wallis for nonparametric multiple groups. The English/Chinese title plus 'RETURNS: 两两比较 P 值' makes the resource unambiguous. It stops short of naming the sibling it displaces (tukey_hsd, the parametric analogue), so differentiation is left implicit.

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 WHEN: pairwise comparisons after Kruskal-Wallis (nonparametric, multiple groups)' gives a clear triggering context that an agent can match against a study design. It also implicitly excludes the parametric case by flagging 'nonparametric'. No explicit when-not or named alternative (e.g., tukey_hsd / two_way_anova) appears, so it falls short of a 5.

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