hypothesis_test

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

With no annotations provided, the description carries the full burden and delivers: it discloses Welch's t-test as a hard specification with Welch-Satterthwaite df, the Shapiro pre-check for 3<=n<=5000 that warns but does not block, always two-sided CI construction, Cohen's d formulas per design, and the exact conclusion wording template. This is exceptional disclosure of statistical behavior beyond what any structured field could convey.

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 long but well-sectioned into parameters, methods, examples, and inline-data notes, with critical constraints front-loaded and worked usage examples included. It loses a point for meta-content that doesn't help invocation, such as the doc-sync maintenance note and the deferral of inline_data limits to an external SPEC.md section.

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 9-parameter tool with no annotations and no output schema, the description covers parameters, statistical methods, pre-check behavior, fallback paths, output highlights (CI, Cohen's d, conclusion template), and examples. The remaining gaps are the absence of a full result-structure specification and error-handling behavior, plus reliance on external docs for inline_data limits.

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 0%, so the description must fully compensate, and it does: every one of the 9 parameters is documented with types, defaults, and constraints (column must be numeric, group_col exactly 2 groups with n>=2, alpha in (0,1), sample2_col paired-aligned). It even documents inline_data's two accepted shapes and its mutual exclusivity with file_path, which the bare array/object union in the schema leaves opaque.

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 opening line identifies it as "统计推断组 · 假设检验（工具 6，核心实现）" — a hypothesis testing tool in the inference group — and the body enumerates the three supported variants (one_sample, independent, paired) with their statistical methods. This clearly separates it from sibling tools like normality_test, anova_test, and chi_square_test, which address different inferential questions.

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?

The description gives concrete selection context: group_col is required and must have exactly 2 groups for independent, sample2_col for paired, and mu0 for one_sample. It also explicitly names nonparametric_test (Wilcoxon/Mann-Whitney) as the fallback when the Shapiro pre-check is violated. It stops short of full when-not routing against siblings like anova_test for 3+ groups, so it earns 4 rather than 5.

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