StatsPAI

synth

Read-only

Run synthetic control and related panel causal-inference methods, including classic SCM, synthetic DiD, augmented/penalized SCM, and staggered adoption, with placebo inference and validation.

Instructions

Synthetic control (Abadie et al.) and its variants through one entry: classic SCM with placebo inference, synthetic DiD, augmented / penalized SCM, generalized SC (gsynth), staggered adoption and more via method=. Panel in long format, one treated unit (staggered: a treatment column instead). 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "outcome": "<outcome>",
      "time": "<time>",
      "unit": "<unit>"
    },
    "name": "synth"
  }
}

Input Schema

Name	Required	Description	Default
`time`	Yes	Period column.
`unit`	Yes	Unit column.
`detail`	No	Payload depth; agent is the fullest.	agent
`method`	No		classic
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`outcome`	Yes	Outcome column.
`placebo`	No	In-space placebo inference.
`data_csv`	No	Small inline table as CSV text.
`as_handle`	No	Cache the fit and return its result_id.
`data_path`	No	Absolute path of a data file on the server.
`result_id`	No	Handle of an earlier fit made with as_handle=true.
`treatment`	No	0/1 column, method='staggered' only.
`covariates`	No	Predictor columns matched on.
`data_records`	No	Small inline table as row objects.
`treated_unit`	No	Value of unit that is treated.
`treatment_time`	No	First treated period.
`max_output_bytes`	No	Result byte budget (default 262144; 0 = none).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint=false, so the description carries the rest and does so substantively: it discloses that output is 'certified evidence with scoped limitations', that certification is specification-specific, that the default outcome-only V=I path is a Kaul-style convention, and that native classical SCM can land on a different local optimum than Synth. These are genuine behavioral caveats an agent could not infer from the schema, though runtime cost and the as_handle caching workflow remain undocumented.

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?

Purpose is front-loaded in the first clause before the method inventory, and each subsequent block (data shape, validation, limitations) covers a distinct concern with no filler. The closing limitations sentence is a long run-on dense with internal jargon and could be split, which keeps it below a 5.

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?

For a 17-parameter tool with an output schema (so return values needn't be explained), the description covers the essentials: data format, the treated-unit constraint, method families, and certification caveats. Gaps remain around the as_handle/result_id caching workflow and the dangling backend/special_predictors references.

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 94%, so the baseline is 3; the description's contribution is the conceptual grouping of the 22 method= values into families (classic, sdid, penalized, gsynth, staggered) plus the note that staggered mode swaps treated_unit for a treatment column. It also references backend='synth' and special_predictors, which are not in the input schema at all, so part of its parameter guidance points at nonexistent knobs.

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?

Names a specific estimator family (synthetic control / Abadie et al.) and enumerates the concrete variants it bundles (classic SCM with placebo inference, synthetic DiD, augmented/penalized SCM, gsynth, staggered adoption), all routed through method=. This clearly separates it from sibling estimators such as did, callaway_santanna, and bacon_decomposition without needing their schemas.

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?

Gives concrete applicability conditions: panel in long format, exactly one treated unit, and a treatment column instead when staggered. It stops short of the top score because it never states when to prefer this over the sibling alternatives (did, callaway_santanna, gsynth-style variants) or what data shapes disqualify it.

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