StatsPAI

dml

Read-only

Estimates causal treatment effects under selection on observables using double/debiased machine learning with cross-fitting for PLR, IRM, PLIV, and IIVM models.

Instructions

Double/debiased machine learning (Chernozhukov et al. 2018) with cross-fitting: partially linear (plr), interactive (irm, binary treatment), and the IV versions (pliv, iivm). Treatment effect under selection on observables with flexible nuisance models. Validation: certified evidence with scoped limitations. Known limitations: external_predictions, store_oof, and observation_ids are Python-only and absent from JSON/MCP inputs; external records accept no dict, JSON string, or file path; store_oof=True retains individual-level records for get_oof() and get_residuals() in memory only; ordinary serialization omits them; Retained IRM needs at least 10 rows per treatment arm in each training fold or raises DataInsufficient instead of fallback; internal explicit fold_indices require n_rep=1, while external repeated IRM records are allowed when the explicit partition is equivalent for every repeat.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "covariates": "<covariates>",
      "treat": "<treat>",
      "y": "<y>"
    },
    "name": "dml"
  }
}

Input Schema

Name	Required	Description	Default
`y`	Yes	Outcome column.
`model`	No		plr
`treat`	Yes	Treatment column.
`detail`	No	Payload depth; agent is the fullest.	agent
`cluster`	No	Cluster column (folds and variance).
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`model_d`	No	Treatment learner; irm uses its classifier.
`model_y`	No	Outcome learner (default gbm).
`n_folds`	No
`data_csv`	No	Small inline table as CSV text.
`as_handle`	No	Cache the fit and return its result_id.
`data_path`	No	Absolute path of a data file on the server.
`result_id`	No	Handle of an earlier fit made with as_handle=true.
`covariates`	Yes	Control columns.
`instrument`	No	Instrument, pliv / iivm only.
`data_records`	No	Small inline table as row objects.
`random_state`	No
`max_output_bytes`	No	Result byte budget (default 262144; 0 = none).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries most of the burden and does so with real substance: Python-only parameters absent from MCP inputs, memory-only retention of OOF records with serialization omitting them, a 10-rows-per-arm-per-fold threshold that raises DataInsufficient instead of falling back, and the n_rep=1 constraint on internal fold_indices. These are genuine failure-mode disclosures rather than restatements, though the fit-caching path via as_handle/result_id is not described at all.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and identification setting are correctly front-loaded, and no sentence is purely filler. But the limitations block is a single run-on chain of semicolon clauses with dense internal jargon (e.g. 'external repeated IRM records are allowed when the explicit partition is equivalent for every repeat'), which is hard to scan and would benefit from being itemized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the 18-parameter surface is largely covered by schema descriptions. The description fills the remaining gaps around data-input constraints and computational failure modes; only the handle/caching workflow is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 83%, so the baseline is 3; the description adds meaning on top by naming parameters that do NOT exist in the JSON/MCP surface (external_predictions, store_oof, observation_ids) and by stating that external records reject dicts, JSON strings, and file paths, which directly constrains how data_records and the external-workflow parameters may be used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific estimator family (double/debiased ML with cross-fitting) and enumerates its four variants (plr, irm, pliv, iivm) with the key qualifier that irm requires a binary treatment. An agent can tell this apart from generic regression/IV siblings by the cross-fitting and nuisance-model framing, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers an implied applicability condition — 'treatment effect under selection on observables with flexible nuisance models' — which tells the agent the identification setting. However, it never contrasts with the sibling estimators (iv, ivreg, feols, causal) that cover overlapping ground, and gives no explicit when-not guidance.

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

dml