Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

staggered_sa

Read-only

Estimates Sun-Abraham causal effects with design-based inference when treatment timing is randomly assigned, using only the last-treated cohort as control.

Instructions

Sun-Abraham's estimand with design-based inference (Roth & Sant'Anna 2023). Identical to sp.staggered_cs except that only the last-treated cohort serves as control, which is what Sun & Abraham's interaction-weighted estimator does. Inference identifies off random adoption timing, not parallel trends. Validation: validated evidence tier (known-truth, reference, external-parity, or Monte Carlo artifact). Do NOT use when: adoption timing was not randomised -- use sp.sun_abraham, whose inference rests on parallel trends instead. Assumptions: treatment timing is randomly assigned; balanced panel. Pre-conditions: balanced panel with at least two cohorts. Alternatives: sp.staggered_rollout, sp.staggered_cs, sp.sun_abraham. Typical minimum N: 50.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`g`	Yes	First-treatment period; never-treated may be 0, NaN or inf
`i`	Yes	Unit identifier
`t`	Yes	Time period
`y`	Yes	Outcome variable column name or outcome array.
`alpha`	No	Significance level for confidence intervals and tests.
`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
`fisher`	No	fisher parameter (bool).
`se_type`	No	Conservative bound, or the adjusted SE R staggered prints	neyman
`estimand`	No	Weighting scheme, as in sp.staggered_rollout	simple
`n_fisher`	No	Number of fisher.
`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.
`event_time`	No	event_time parameter (float or list).
`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.6/5.0

Behavior5/5

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

Annotations only signal read-only and closed-world behavior, so the description carries the burden and does it well: it reveals that inference identifies off random adoption timing rather than parallel trends, notes the last-treated cohort as control, and states balanced-panel requirements. There is no contradiction with the readOnlyHint.

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 front-loaded with the core method and then covers exclusions, assumptions, alternatives, and sample size in a compact, structured way. The only minor weakness is the slightly redundant 'Validation: validated evidence tier' line, but overall every sentence adds decision-relevant content.

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 methodologically nuanced staggered-DiD tool, the description provides the identifying assumption, contrast with parallel-trends estimators, applicability conditions, alternatives, and a minimum sample size. Combined with the rich schema and output schema, an agent has enough to select and invoke the tool correctly.

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?

The input schema has 100% coverage, so the schema already documents all parameters. The description adds no parameter-level syntax or semantics beyond the schema, which matches the baseline of 3 for fully covered schemas.

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 specific estimand (Sun-Abraham) and inference mode (design-based), and immediately distinguishes it from sp.staggered_cs by the control-group construction. It also names related alternatives, so an agent can identify this tool among the many staggered/event-study siblings.

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?

The description explicitly says when NOT to use the tool ('adoption timing was not randomised') and names the replacement (sp.sun_abraham) whose inference assumption differs. It also lists assumptions, pre-conditions, alternatives, and a typical minimum N, giving the agent clear 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