Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

dl_propensity_score

Read-only

Estimate propensity scores with a neural network to balance treatment and control groups for causal effect estimation, enabling adjustment for observed confounders.

Instructions

Neural-net propensity score estimator (arXiv:2404.04794, 2024). Assumptions: Unconfoundedness / selection on observables: treatment is conditionally independent of potential outcomes given covariates; Overlap (positivity): 0 < e(X) < 1 for all units (scores are clipped to [0.02, 0.98]); Covariates are pre-treatment and the MLP correctly approximates e(X) = P(T=1 | X). Pre-conditions: Cross-sectional or pooled DataFrame with a binary treatment column and numeric covariate columns; No missing values in the covariate matrix passed to the network; Enough observations per treatment arm to fit a small MLP without overfitting. Failure modes: Heavy clipping at 0.02/0.98 indicates near-deterministic treatment and positivity violation -> Trim or restrict to the region of common support before using the scores in a weighted estimator; torch absent and sklearn MLP fails to converge in max_iter with lbfgs -> Increase max_iter, scale covariates, or shrink hidden_sizes for a simpler network. Alternatives: sp.overlap_weighted_did, sp.drdid, sp.did. Typical minimum N: 200.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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
`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`	Yes	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.
`treatment`	Yes	Treatment indicator, treatment variable, or treatment array.
`covariates`	Yes	Covariate matrix, DataFrame, or column names.
`data_columns`	No	Optional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
`hidden_sizes`	No	hidden_sizes parameter (list).
`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.7/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses score clipping to [0.02, 0.98], positivity-violation signals, sklearn/torch convergence failure modes, and typical minimum N. No contradiction with annotations is present: the default path is a non-mutating estimator.

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

Conciseness5/5

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

The description is dense but well-structured with labeled sections: Assumptions, Pre-conditions, Failure modes, Alternatives, and Typical minimum N. Every sentence earns its place and the most identifying content is front-loaded.

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

Completeness5/5

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

For a 9-parameter estimator with an output schema, the description covers validity assumptions, failure modes, remediations, sample-size guidance, and alternatives. Anything omitted, like data_path formats, is already documented in the input schema.

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 the baseline is 3, but the description adds genuine meaning: treatment must be binary, covariates must be numeric and missing-free, and hidden_sizes should be shrunk for simpler networks. This goes beyond the schema's generic 'parameter (list)' text.

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?

Opens with 'Neural-net propensity score estimator' and defines the estimand as e(X)=P(T=1|X), making the operation and resource unmistakable. The arXiv reference and 'propensity score estimator' wording clearly separate it from siblings like propensity_score or DID-focused tools.

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?

Assumptions and pre-conditions state when the estimator is valid, and failure modes give concrete corrective actions such as trimming or shrinking hidden_sizes. Alternatives are named explicitly, but without sharp decision rules for choosing sp.overlap_weighted_did, sp.drdid, or sp.did over this tool.

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

Deploy Server