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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: results come from a real algorithm engine rather than LLM generation, implying deterministic, reproducible output. It says nothing about assumptions (normality, balanced design), handling of missing data, or failure behavior, which matters for a statistical test.

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 description is short and front-loads the technique name and the usage condition. It does repeat itself, saying 主效应与交互 twice (once as the goal, once as the return value), which is minor waste. The parenthetical about the algorithm engine is brief and earns its place as a trust signal.

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 three-parameter, non-destructive statistical tool with no output schema, the core information is present. What is missing is guidance on the optional `values` parameter, input formatting expectations (arrays of strings, equal group structure), and any statement about statistical assumptions — gaps that matter for correct invocation.

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 each of the three parameters is already documented in the schema; the baseline of 3 applies. The description adds no meaning beyond that, and notably does not clarify why `values` is listed as optional when an ANOVA requires observations — a point an agent could easily get wrong.

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 specific technique (双因素方差分析 / two-way ANOVA) and states what it produces: main effects and interaction effects. This is a clear verb+resource statement an agent can act on. It does not, however, distinguish itself from statistical siblings such as act_tukey_hsd or act_lmm_formula, 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?

"用户有两个因素要看主效应与交互作用" gives an explicit trigger condition: use when there are two factors and the question is about main effects plus interaction. That is genuine when-to-use guidance. It offers no exclusions or named alternatives (e.g., post-hoc comparison tools or regression-based approaches), which keeps it from a 5.

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