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. The description adds genuinely non-redundant context: results are computed by a real algorithm engine rather than generated by an LLM, and the return includes the statistic, P value, 95% CI and an interpretation. It does not discuss failure modes such as an invalid tool_id or malformed payload.

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 structure is front-loaded: bracketed identity, then the when-to-use rule, then the category/method inventory, then the return contract. Every part maps to a decision the agent must make. The long parenthetical method list is somewhat padded, though it does serve selection.

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 dispatcher over a nested payload with 100% schema coverage and no output schema, the description covers routing, execution semantics and return contents, which is most of what an agent needs. What remains thin is guidance on payload shape per tool family, though the schema description enumerates the common field names.

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 both tool_id and payload are already documented, including the enum list and the common payload field names. The description's contribution is mainly the six-category grouping and method examples, which help map a user request onto a tool_id but largely restate the schema enum. Baseline 3 is appropriate given 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?

The description states a specific role: a single dispatch entry point that runs any of 97 statistical tests selected by tool_id, grouped into six named categories (difference comparison, association, survival, diagnostics, cohort preprocessing, evidence synthesis). It enumerates concrete example methods (Kappa, Bland-Altman, ICC, VIF, PCA, Friedman, McNemar, runs test, sign test, trend chi-square, Meta components), so an agent immediately knows this is a router for statistical analysis rather than a single-test tool.

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?

It gives an explicit selection rule: use this when the desired statistical test is not already covered by a dedicated sibling tool. That is a real when-to-use condition tied to the alternative set. It stops short of naming which siblings take precedence (e.g. act_tukey_hsd, act_km_curve, act_roc, act_two_way_anova, act_distribution_fit), so the agent must still infer the boundary cases.

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