focal_cate

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

Since readOnlyHint=true is already declared, the description adds substantial behavioral context beyond the annotations: unconfoundedness, overlap, consistent nuisance estimation, cross-fitting, failure modes, and a typical minimum N of 500. This is far more than a bare 'estimates CATE' statement and helps the agent anticipate statistical conditions and failure risks.

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 first sentence establishes the estimator's purpose, and the remaining content is organized into scannable labeled sections: Validation, Assumptions, Pre-conditions, Failure modes, Alternatives, and Typical minimum N. Every section carries useful information, with no filler or repeated schema content.

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 complex statistical tool with 11 parameters and an output schema, the description covers the statistical assumptions, data requirements, failure modes, alternatives, and sample-size guidance. There is no need to describe return values because an output schema is provided, and annotations already convey the read-only safety profile.

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, but the description adds value by framing the required covariates/treatment/outcome in statistical terms and by giving a concrete 'Typical minimum N: 500' guideline. This goes beyond the schema's field-level descriptions and helps an agent judge whether the data are sufficient.

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 'Functional doubly-robust CATE estimator,' which precisely identifies the operation and target quantity without being a tautology. It also sets the tool apart by naming alternative estimators (sp.dml, sp.causal_forest, sp.tmle), so an agent can immediately place it among sibling tools.

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 lists explicit alternatives and gives clear preconditions ('Covariates, a treatment indicator, and an outcome for each unit; Enough data to fit flexible nuisance models'). It doesn't provide a detailed decision rule for choosing among the named alternatives, but the assumptions and failure-mode guidance strongly imply when this estimator is appropriate.

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