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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered structurally; the description adds the return contract (statistic, P value, 95% CI, interpretation) that annotations cannot express. It does not disclose failure behavior for an invalid or mismatched tool_id/payload combination, which for a 97-way dispatcher would be the most valuable added detail.

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?

Front-loaded with the USE WHEN condition before aliases and returns, and each tag block carries distinct information. The multilingual ALIASES list is long relative to its value for an agent and adds bulk, but it is at least clearly delimited rather than woven into prose.

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 2-parameter dispatcher with no output schema, the description covers what it does, when to call it, and the return shape. What is missing is guidance on composing the nested payload per selected tool and on behavior when tool_id and payload disagree, which matters given 97 possible parameter shapes.

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%, and the payload property already enumerates the common field shapes (group1/group2, groups, values, x/y, es/se, features/label), so the schema does the heavy lifting. The description only echoes 'pass tool_id'. Baseline 3 applies since little meaning is added beyond the structured fields.

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 names the resource (a bundle of 97 statistical tests behind a single tool_id) and gives concrete example families (Kappa, ICC, Bland-Altman, VIF, PCA, Friedman, McNemar, runs test). It explicitly positions itself relative to siblings with 'any statistical test not covered by a dedicated tool'. The boundary is still fuzzy, however: siblings like tukey_hsd, dunn_posthoc and two_way_anova overlap with tool_ids listed in the schema (posthoc, anova), so an agent cannot fully resolve routing from the text alone.

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?

A clear 'USE WHEN' clause states the selection condition: tests lacking a dedicated tool, with a concrete list of covered test families. This is more than implied usage. It stops short of explicit exclusions or a decision rule for the overlapping sibling tools (e.g., when to prefer tukey_hsd over this tool's posthoc id), which keeps it below a 5.

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