chi_square_test

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

With no annotations, the description carries the full behavioral burden and exceeds it: deterministic pipeline, binning rule, error conditions for unique values, Fisher exact fallback with OR/df=null, Cramér's V formula, expected-frequency caveat, and the 'association ≠ causation' warning. An agent can predict side effects and failure modes.

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?

Purpose, parameters, deterministic flow, example, and inline-data note are laid out in a logical, front-loaded order with negligible redundancy. The only nonoperational sentence is the docstring-synchronization maintenance note, preventing a perfect 5.

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?

Despite no annotations and no output schema, the description covers input constraints, preprocessing, test selection, effect size, edge-case errors, conclusion template, and caveats. It even names the statistics an agent can expect in the result (chi2, expected frequencies, OR, df, Cramér's V).

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 coverage is 0% and has four nullable params with no descriptions. The tool description documents file formats for file_path, the mutual exclusivity and two accepted shapes of inline_data, and the required existence plus auto-binning behavior for col_a/col_b. This is exactly the operational semantics the schema lacks.

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 a specific statistical operation ('卡方独立性检验') and a specific resource (association between two categorical columns), immediately distinguishing it from generic inference siblings. The example call and the '两列类别变量' requirement make the scope unambiguous.

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 clear input context: two categorical columns are needed, numeric columns get auto-binned, and file_path/inline_data are mutually exclusive. However, it never explicitly says when to prefer this tool over siblings such as nonparametric_test or correlation_matrix, so alternative routing is left to inference.

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