Causal Decision Agent

by vikranthviki

Overview Schema Source Related Servers Discussions Admin

Python

Local

psmatch2

Read-only

Matches treated and control units on propensity scores, then returns ATT, standard errors, and balance diagnostics.

Instructions

Stata psmatch2-faithful supported propensity-score matching paths (nearest-neighbour, kernel, radius, local linear regression, Mahalanobis): returns matched-sample variables (_pscore _treated _support _weight _y; plus _n1 through _nn _pdif for nearest-neighbour), the psmatch2 analytic ATT standard error, plus post-matching balance (.pstest() reproduces Stata pstest exactly), common-support plotting, and weighted PSM-DID. Validation: certified parity evidence. Assumptions: Unconfoundedness / CIA: Y(d) perp D | X; Overlap / common support on the propensity score; SUTVA: no interference between matched units. Pre-conditions: binary treatment 0/1; covariates are pre-treatment (temporally prior to D); enough control units for each treated unit under k:1 matching. Failure modes: Residual imbalance after matching (max |SMD| > 0.1) -> Tighten caliper, add covariate interactions (ps_poly), or switch to sp.ebalance; Treated units off common support -> Pass common_support='minmax' (Stata common) or sp.trimming. Alternatives: sp.match, sp.psm, sp.ebalance, sp.cbps. Typical minimum N: 200.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ai`	No	Abadie-Imbens (2006) robust SE with J within-arm matches (Stata ai(J))
`se`	No	Standard-error estimator. 'bootstrap' re-estimates the propensity score each replication and is the only valid choice for method='llr' (Stata reports seatt = . there).	psmatch2
`treat`	Yes	Binary treatment column (0/1)
`bwidth`	No	Kernel bandwidth (method='kernel')
`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
`kernel`	No	Kernel type (method='kernel' or 'llr'). NOTE: Stata's psmatch2 does not run LLR with kerneltype(epan) -- it substitutes lpoly-smoothed nearest-neighbour matching. Use 'tricube' to reproduce psmatch2's own LLR routine.	epan
`method`	No	Matching algorithm	neighbor
`caliper`	No	Max PS distance / radius bandwidth
`outcome`	No	Outcome variable (Stata outcome(); optional)
`neighbor`	No	Number of nearest neighbours k
`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.
`covariates`	Yes	Covariate matrix, DataFrame, or column names.
`data_columns`	No	Optional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
`data_sample_n`	No	Optional uniform random subsample size (seed=0, deterministic) — useful on huge panels.
`bootstrap_reps`	No	Bootstrap replications when se='bootstrap'
`bootstrap_seed`	No	Seed for the bootstrap resampler (pass for reproducibility)
`common_support`	No	Common-support trimming	none
`llr_stata_compat`	No	method='llr' only: reproduce Stata psmatch2's SUBSTITUTE for LLR (lpoly-smoothed outcome + nearest-neighbour matching) instead of genuine local linear regression. Set only to reconcile a published psmatch2 number.

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.9/5.0

Behavior5/5

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

Annotations only provide readOnlyHint and openWorldHint, so the description carries the behavioral disclosure burden. It reveals generated variables (_pscore, _treated, _support, _weight, _y, and NN-specific ones), the analytic ATT SE, exact pstest reproduction, common-support plotting, weighted PSM-DID, validation parity, and failure modes. There is no contradiction with the read-only annotation.

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 front-loaded with core purpose and return contract before assumptions, preconditions, failure modes, and alternatives. Every section earns its place, and the semicolon-driven formatting keeps a 20-parameter tool's overview compact and scannable.

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 high-complexity tool with 20 parameters, the description covers all essential context: methods, outputs, statistical assumptions, preconditions, failure-mode remedies, alternatives, and minimum sample size. An output schema exists, so return-value details are already handled elsewhere; nothing critical for selecting or invoking the tool is missing.

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%, giving a baseline of 3. The description adds meaningful parameter-level guidance beyond the schema, such as passing common_support='minmax' to handle off-support treated units and tightening the caliper to address residual imbalance. It does not enumerate every parameter, so it stays below a 5.

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 description states a concrete resource and action: psmatch2-faithful propensity-score matching with five named methods, returning matched-sample variables, ATT standard errors, balance diagnostics, plotting, and PSM-DID. It distinguishes itself from sibling propensity-score/matching/balance tools by naming psmatch2 fidelity and the specific outputs it reproduces.

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

Usage Guidelines5/5

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

It gives explicit pre-conditions: binary 0/1 treatment, pre-treatment covariates, and enough control units for k:1 matching. It also names alternatives (sp.match, sp.psm, sp.ebalance, sp.cbps) and routes agents to caliper/common-support adjustments or ebalance/trimming when failure modes appear.

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

Deploy Server