Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

cate_eval

Read-only

Evaluate any CATE estimator using RATE, AUTOC, or Qini metrics, producing validated evidence and actionable diagnostics for reliable treatment-effect decisions.

Instructions

Evaluate any CATE estimator via RATE / AUTOC / Qini (Yadlowsky 2025). Validation: validated evidence tier (known-truth, reference, external-parity, or Monte Carlo artifact). Assumptions: Unconfoundedness given the covariates; Overlap / positivity across the covariate space; Nuisance functions are estimated consistently; cross-fitting controls overfitting bias. Pre-conditions: Covariates, a treatment indicator, and an outcome for each unit; Enough data to fit flexible nuisance models with sample-splitting / cross-fitting. Failure modes: CATE estimates are unstable or extrapolate beyond the covariate support -> Restrict to the overlap region, increase data, or use a doubly-robust learner (DR-/R-learner). Alternatives: sp.dml, sp.causal_forest, sp.tmle. Typical minimum N: 500.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`T`	Yes	Observed outcome and binary treatment.
`X`	No	Required if any of ``e_hat / m_hat / mu1_hat / mu0_hat`` is None; cross-fit nuisances are estimated with GBM defaults.
`Y`	Yes	Observed outcome and binary treatment.
`cate`	Yes	Estimated CATE :math:`\hat\tau(X_i)` from any estimator.
`clip`	No	Propensity clip.
`alpha`	No	Significance level for confidence intervals and tests.
`e_hat`	No	Pre-computed nuisance predictions (e.g., from the same estimator that produced ``cate``). If provided, no internal cross-fitting runs.
`m_hat`	No	Pre-computed nuisance predictions (e.g., from the same estimator that produced ``cate``). If provided, no internal cross-fitting runs.
`detail`	No	Payload 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
`q_grid`	No	Grid of q values to evaluate.
`target`	No	Which scalar headline to emit; both are computed and returned.	AUTOC
`mu0_hat`	No	Pre-computed nuisance predictions (e.g., from the same estimator that produced ``cate``). If provided, no internal cross-fitting runs.
`mu1_hat`	No	Pre-computed nuisance predictions (e.g., from the same estimator that produced ``cate``). If provided, no internal cross-fitting runs.
`n_folds`	No	Number of cross-fitting or cross-validation folds.
`as_handle`	No	If 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_path`	No	Absolute 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_id`	No	Optional 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.
`data_columns`	No	Optional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
`random_state`	No	Random seed or RandomState for reproducible stochastic steps.
`data_sample_n`	No	Optional uniform random subsample size (seed=0, deterministic) — useful on huge panels.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 15, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With readOnlyHint=true already covering the non-destructive nature, the description still adds substantial value: it discloses validation evidence tiers, statistical assumptions, cross-fitting requirements, and failure-mode responses. This goes well beyond the annotations alone.

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?

The description is compact and well-sectioned, front-loading the core purpose before assumptions, preconditions, and failure modes. The 'Typical minimum N: 500' line is slightly extraneous but not wasteful, and the label-based structure makes the information easy to scan.

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?

Given the tool's complexity — 20 parameters, an output schema, and many siblings — the description covers the essential non-schema context: assumptions, evidence validation, preconditions, and failure handling. It does not need to explain return values because an output schema exists, though it could have explicitly mapped parameter names like T and Y to treatment/outcome roles.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3 even without parameter details in the description. The description mentions treatment, outcome, covariates, and nuisance functions generically, but it does not disambiguate the schema's confusingly identical T and Y descriptions. It neither harms nor meaningfully enriches the schema's parameter explanations.

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

Purpose5/5

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

The first sentence states a specific action and resource: 'Evaluate any CATE estimator via RATE / AUTOC / Qini.' This clearly distinguishes it from estimation-focused siblings like sp.causal_forest or tmle, while the alternatives section reinforces its evaluation role.

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?

The description provides clear context: use this after obtaining CATE estimates, with pre-conditions such as covariates, treatment, outcome, and sufficient data. It names alternatives (sp.dml, sp.causal_forest, sp.tmle) but does not explicitly state when to choose them over cate_eval, so it falls just short of full routing guidance.

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

Deploy Server