effect_size

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses exact formulas, normal-approximation CI construction with 1.96*se, explicit labeling of '正态近似', empirical thresholds, simplifications (no bootstrap CI, no distribution tests, cliff_delta lacks a paired version), and the deterministic paired-matching semantics without ID columns.

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 dense and information-rich, with formulas, defaults, simplification notes, and an example all earning their place. It is long but well organized by labeled sections. Minor verbosity exists around docstring maintenance references and the inline_data section, which could be tightened without losing value.

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?

Given the tool's complexity, six parameters, no output schema, and no annotations, the description is nearly complete: it covers inputs, method semantics, constraints, and output caveats. The main gap is that it does not explicitly specify the shape or keys of the returned result object, only indicating that the CI will be labeled as '正态近似'.

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 and does fully compensate. Every parameter is explained: file_path and inline_data are explicitly alternatives, group_col and value_col have constraints, method lists valid options with defaults, and paired describes the equality requirement and matching convention. This goes well beyond the bare schema types.

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 clearly identifies the tool as an effect-size calculator for statistical inference, and lists the supported methods (cohens_d, hedges_g, cliff_delta) plus the input roles (group_col, value_col). It is specific about what the tool computes, though it does not explicitly contrast itself with sibling tools such as hypothesis_test or nonparametric_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?

The description gives operational constraints (e.g., group_col must have exactly 2 groups, paired samples must have equal sizes) and notes simplification choices, but it provides no explicit guidance on when to choose this tool over alternatives like hypothesis_test, anova_test, or confidence_interval. The usage context is implied rather than stated.

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