two_sample_t_test

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

The annotation layer already declares readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. The description adds behavioral value by disclosing that with default settings it runs Welch's test (which does not assume equal variances) and how to switch to the classic test. A slight deduction is appropriate as it doesn't mention return values (test statistic, p-value, confidence intervals), but for a read-only statistical test, the current disclosure is quite complete.

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?

Two perfectly-formed sentences with zero filler. The phrasing is front-loaded with the verb+resource, the default behavior is stated, and the alternative path is given as a conditional, making it easy for an agent to parse quickly.

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 statistical hypothesis test with 100% schema coverage and no output schema required, the description covers the statistical assumptions, defaults, and usage context comprehensively. It doesn't mention return values, but for a non-destructive, deterministic test, the key information (null hypothesis, inputs, and key parameter) is present.

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?

With 100% schema coverage, the parameters are already well-documented (a and b as independent samples; alpha and equal_var with defaults and clear descriptions). The description adds semantic depth by explaining the statistical implication of equal_var=false (Welch's test) versus equal_var=true (pooled-variance test), complementing the schema's mechanical definitions.

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 opens with a clear, specific verb+resource statement: 'Test whether two independent samples have different means.' It precisely scopes the operation (two independent samples, means comparison) and differentiates the default Welch's t-test from the classic pooled-variance version, distinguishing it from siblings like paired_t_test or one_sample_t_test.

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?

Explicitly states when to use this tool (for two independent samples testing mean differences) and the default behavior (Welch's test that assumes unequal variances). It also explicitly tells the agent when to pass equal_var=true for the alternative pooled-variance test, giving clear context on parameter-driven usage decisions.

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