doubly_robust

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

Annotations already mark this read-only, and the description adds the statistical behavior that matters: the double-robustness consistency condition, the failure mode (biased estimate when both nuisance models are misspecified), and a mitigation (cross-fit or validate each nuisance separately). No contradiction with readOnlyHint=true.

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 organized into labeled sections (Assumptions, Pre-conditions, Failure modes, Alternatives, Typical minimum N) and is front-loaded with method identity. It is dense and the failure-mode sentence is a run-on, but every section earns its place for an estimator with strong statistical assumptions.

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 14-parameter estimator with an output schema (so return values need no explanation), the description covers validity conditions, prerequisites, failure modes, alternatives, and a sample-size rule of thumb. The main gap is the absence of explicit guidance on when to prefer IPS/SNIPS/DM over DR.

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 schema already documents all 14 parameters and the baseline is 3. The description adds limited mapping context — pre-conditions mention X, A, R, logging propensities, and a fitted Q-model — which helps interpret pi_behavior and pi_target conceptually, but it does not detail parameter formats or interactions beyond that.

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 'Doubly-robust OPE (Dudik et al. 2011)', naming a specific, citable estimator, and explains its defining property: consistent if either the outcome or propensity model is correctly specified. The verb and resource are somewhat implied by the method name rather than stated explicitly, and sibling differentiation comes only later via the Alternatives line.

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 names sibling estimators (sp.ips, sp.snips, sp.direct_method) and lists validity assumptions (positivity, no unmeasured confounding) along with pre-conditions, which together delineate when the estimate is trustworthy. It stops short of an explicit when-to-use-this-versus-that contrast, so the agent must infer the decision rule among alternatives.

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