Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

synth

Read-only

Estimates causal impact by building a synthetic control from donor units and comparing outcomes against a weighted counterfactual, with multiple SCM variants and inference options.

Instructions

Unified synthetic control estimator. method= selects variant: 'classic', 'demeaned', 'detrended', 'unconstrained', 'elastic_net', 'augmented', 'sdid', 'gsynth', 'staggered'. inference= selects: 'placebo', 'conformal', 'bootstrap', 'jackknife'. Validation: certified evidence with scoped limitations. Known limitations: Classical SCM certification is specification-specific: ADH/Synth parity requires passing the same special_predictors recipe; the default outcome-only V=I path is a documented Kaul-style convention; Default native classical SCM can differ from Synth on Basque-style panels by a documented local-optimum convention (the outer V optimisation has multiple near-equivalent minima); use backend='synth' or canonical special_predictors when exact R parity is required. Do NOT use when: many units are treated at once -- classic SCM is built for one (or few) treated units; use sp.gsynth, sp.sdid or sp.callaway_santanna; the pre-treatment window is short (fewer than ~10 periods) -- the donor weights overfit noise and pre-period fit stops being evidence; the treated unit's pre-period outcome lies outside the convex hull of the donors -- no non-negative weighting can match it; check t...

Input Schema

TableJSON Schema

Name	Required	Description	Default
`time`	Yes	Time period column.
`unit`	Yes	Unit identifier column.
`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
`method`	No	SCM variant: classic/demeaned/detrended/unconstrained/elastic_net/augmented/sdid/gsynth/staggered	classic
`backend`	No	Optional reference backend for exact R parity: synth for classic SCM	native
`outcome`	Yes	Outcome variable column name or outcome array.
`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://.
`inference`	No	Inference method: placebo/conformal/bootstrap/jackknife
`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`	No	Binary treatment column (staggered only)
`data_columns`	No	Optional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
`treated_unit`	No	Treated unit (not needed for staggered)
`data_sample_n`	No	Optional uniform random subsample size (seed=0, deterministic) — useful on huge panels.
`treatment_time`	No	First treatment period

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

Behavior5/5

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

Goes well beyond the readOnlyHint by disclosing scoped validation limitations, Kaul-style outcome-only convention, local-optimum convention, overfitting risk with short pre-periods, and convex-hull infeasibility. No contradiction with annotations.

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 long but structured with clear sections (variant selection, inference selection, limitations, do-not-use). It is front-loaded with the core purpose and method choices. The text ends mid-sentence ('check t...'), which slightly weakens structure, but the existing content is high-density 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 complex 15-parameter estimator, the description covers purpose, method/inference enums, key limitations, and routing to alternatives. Required data columns and output behavior are already handled by the 100%-covered input schema and the presence of an output schema.

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 schema already explains every parameter. The description adds context around method/inference choices and the backend parity condition, but largely restates what the enum/property descriptions already convey.

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 identifies a specific resource ('Unified synthetic control estimator') and lists method/inference variants, making the tool's role clear. It does not explicitly contrast itself with close siblings like robust_synth or augsynth, though its 'unified' framing and method enum imply broad coverage.

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?

Provides explicit 'Do NOT use when' conditions with named alternatives (sp.gsynth, sp.sdid, sp.callaway_santanna) and warns about short pre-treatment windows and convex-hull violations. Also gives conditional guidance for exact R parity via backend='synth' or canonical special_predictors.

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

Deploy Server