bcf

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is known. The description adds valuable behavioral context beyond that: it discloses failure modes (MCMC non-convergence, prior sensitivity), preconditions (internal propensity model to limit confounding), and guidance for remediation (increase draws, re-scale outcome, report diagnostics). This is strong additional transparency, though it could also mention the output format or side effects, but since output schema exists, a 4 is appropriate.

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 a single dense paragraph that front-loads the purpose and then systematically covers validation, assumptions, pre-conditions, failure modes, alternatives, and typical N. Each sentence serves a purpose. While packed, it is organized and efficient, earning a 4 rather than a 5 because it is somewhat dense and could be slightly more scannable with bullet points.

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 (15 parameters, Bayesian estimation), the description covers essential context: assumptions, preconditions, failure modes, alternatives, and sample size guidance. An output schema exists, so return values are covered. It does not mention specific details like expected runtime or data formatting beyond what schema lists, but for the agent to call it correctly, the description is largely sufficient. A 4 is justified.

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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add parameter-specific detail beyond what the schema already provides (e.g., it doesn't explain nu_mu vs nu_tau semantics). However, the schema descriptions are adequate on their own. The description adds contextual meaning about the overall method but not per-parameter, so 3 is correct.

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 states a specific verb and resource: 'Estimate heterogeneous treatment effects using Bayesian Causal Forest.' It clearly distinguishes BCF from sibling tools like sp.dml, auto_cate, and causal_forest by naming them as alternatives. The purpose is unambiguous and actionable.

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 provides explicit pre-conditions (covariates, treatment, outcome), assumptions (unconfoundedness and overlap, prior appropriateness), and names alternatives (sp.dml, sp.auto_cate, sp.causal_forest). It also gives a typical minimum N (250), which helps the agent decide when the tool is appropriate. This is clear and actionable guidance.

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