Skip to main content
Glama
vikranthviki

Causal Decision Agent

by vikranthviki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

dml

Read-only

Estimate causal treatment effects from observational data using double/debiased machine learning with cross-fitting and orthogonal scores.

Instructions

Double/Debiased Machine Learning for treatment effect estimation. Supports partially linear (PLR), interactive regression (IRM, binary D), partially linear IV (PLIV), and interactive IV (IIVM, binary D/binary Z -> LATE). Validation: certified parity evidence. Assumptions: Unconfoundedness: Y(d) perp D | X (conditional ignorability); Overlap: 0 < P(D=1 | X) < 1 for the estimand support (strong for IRM); Nuisance-function estimators converge at op(n^{-1/4}) -- fast enough that orthogonal moments give sqrtn CATE. Pre-conditions: data is tabular (DataFrame); covariates include all confounders conditional on which unconfoundedness holds; cross-fitting folds >= 2 (default 5) -- more folds -> lower variance, higher compute; for irm / iivm: treatment (and for iivm: instrument) is binary 0/1. Failure modes: Extreme propensity scores (~ 0 or 1) -> Trim sample to 0.05 < e(x) < 0.95 or use overlap weights (sp.overlap_weights); Nuisance models cross-val R2 near zero -> Nuisances not learnable -- DML bias guarantees don't apply; re-featurize or pick a different model family; Large Monte-Carlo variance across folds (n_rep > 1) -> Increase n_rep to 10+ and aggregate by median; check for leakage....

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yYesOutcome
modelNoDML model familyplr
n_repNoRepeated cross-fitting splits (median aggregation)
scoreNoOrthogonal score variant (DoubleML-compatible). PLR: 'partialling out' (default) or 'IV-type'. IRM: 'ATE' (default) or 'ATTE'. None selects the model default; defaults reproduce historical output exactly.
treatYesTreatment variable
detailNoPayload depth: 'minimal' (~150 tokens) for sub-step calls where only the point estimate is needed; 'standard' (~1K tokens) for diagnostics + coefficient table; 'agent' (~2K tokens, default) adds violations / next_steps / suggested_functions so the LLM can plan its next call without another round-trip.agent
n_foldsNoCross-fitting folds
as_handleNoIf true, cache the fitted result on the server and return result_id + result_uri alongside the JSON payload so a subsequent tools/call can chain without re-running.
data_pathYesAbsolute path or URL to a data file. Supported: .csv / .tsv / .txt (delimited), .parquet / .pq, .feather / .arrow, .xlsx / .xls, .dta (Stata), .json / .jsonl. Schemes: file://, s3://, gs://, https://.
result_idNoOptional handle to a previously-fitted result (returned by an earlier call when as_handle=true). Tools that operate on a fitted object accept this in place of re-supplying data_path + columns.
covariatesYesList of control variable names
instrumentNoInstrument (required for pliv/iivm)
data_columnsNoOptional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
data_sample_nNoOptional uniform random subsample size (seed=0, deterministic) — useful on huge panels.
normalize_ipwNoSelf-normalize the inverse-propensity weights for the IPW models (irm/iivm); matches DoubleML's normalize_ipw. Rejected for plr/pliv.
trimming_thresholdNoSymmetric propensity clip [t, 1-t] for irm/iivm (DoubleML trimming_rule='truncate'). Default 0.01 = historical clip.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true; the description adds statistical behavior: op(n^{-1/4}) convergence requirement, trimming recommendations, leakage warning, and cross-fitting variance behavior. This goes well beyond the annotation safety profile without contradicting it.

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

Conciseness4/5

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

Dense but organized into definition, validation, assumptions, pre-conditions, and failure modes. The length is justified by the tool's complexity, though it runs long and ends with an ellipsis signalling truncation.

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?

Covers supported models, statistical assumptions, input pre-conditions, failure modes, and remedies. With an output schema present and every parameter described in the schema, the description is sufficiently complete for correct invocation; only a short example is absent.

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 100%, so baseline is 3. The description adds meaning to model families (binary D for IRM/IIVM, binary Z for IIVM->LATE), n_rep (median aggregation), and n_folds (variance/compute tradeoff), plus overlap/trimming context tied to the trimming_threshold parameter.

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?

The description opens with 'Double/Debiased Machine Learning for treatment effect estimation' and enumerates the four supported model families (PLR, IRM, PLIV, IIVM), giving a clear resource and scope. It does not explicitly name sibling tools like dml_panel or dml_sensitivity, so some differentiation is left to the name and context.

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

Usage Guidelines4/5

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

Includes explicit assumptions (unconfoundedness, overlap), pre-conditions (tabular data, folds >= 2, binary treatment for IRM/IIVM), and failure-mode remedies (trim extreme propensities, increase n_rep, re-featurize). It names an alternative (sp.overlap_weights) for extreme propensities but does not contrast with sibling DML-family tools.

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

Deploy Server

Other Tools