conformal_fair_ite

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

Annotations already mark the tool as read-only, and the description adds substantial context beyond that: explicit statistical assumptions (exchangeability, counterfactual fairness, ITE ignorability/overlap), failure modes for sparse strata and protected-column leakage, and a validation evidence tier. There is no contradiction with readOnlyHint=true since the operation is pure computation.

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-organized into labeled sections (Validation, Assumptions, Pre-conditions, Failure modes, Alternatives), with the core purpose front-loaded in the first sentence. Every section contributes operational value and earns its place for a tool with 11 parameters.

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?

An output schema exists, so return values need no description. The definition covers prerequisites, assumptions, failure modes, and alternatives, making it nearly complete for an agent to decide when and how to call it. The only gaps are the truncated alternatives list and the phantom test_data reference, which keep it from a perfect score.

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 the baseline is 3. The description adds pre-conditions about calibration sets and protected-stratum grouping, but it also references an 'optional test_data' parameter that does not appear in the input schema, which could mislead an agent. No additional meaning is provided for alpha, detail, as_handle, or the other schema-documented parameters.

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 method ('Counterfactual-fair conformal prediction for ITE') and immediately differentiates it from siblings like conformal_ite and conformal_synth by the demographic-parity adjustment. The verb 'wraps' and the outcome ('distribution-free coverage under protected-attribute shifts') make the function's role unmistakable.

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?

Pre-conditions clearly state the required data shape (y, treat, predictive covariates, protected column) and the calibration-set prerequisite, and failure modes give actionable remediation steps. However, the description never explicitly tells the agent when to choose this tool over conformal_ite or other conformal variants; the alternatives line is truncated ('sp.conformal,...'), leaving the selection rule 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.