Skip to main content
Glama
vikranthviki

Causal Decision Agent

by vikranthviki

local_projections

Read-only

Estimate impulse responses across multiple horizons with local projections, adding controls, Newey-West confidence bands, and cumulative responses to support causal impact decisions.

Instructions

Estimate impulse responses via Jorda (2005) local projections. Validation: certified parity evidence. Assumptions: Outcome and shock series are (covariance-)stationary so horizon-h projections are not spurious; Shock is conditionally exogenous at t given controls and the auto-added lags (no contemporaneous feedback from y_t to shock_t); Newey-West truncation lag is adequate for the moving-average serial correlation induced by overlapping horizons. Pre-conditions: Single time-ordered series in a DataFrame with the outcome and shock columns; For identification='lpirfs_cholesky', endog_order contains the outcome and shock columns in the intended Cholesky ordering; Length comfortably exceeds horizons + max lag so the deepest horizon regression retains enough usable rows. Failure modes: Confidence bands explode or flip sign at long horizons after passing already-lagged controls together with auto_lag=True -> Set auto_lag=False for a bare specification, or drop your manual lags so collinear duplicate-lag columns are not formed; The horizon-0 response is zero when the shock is ordered after the response variable -> Use the intended endog_order, or switch back to identification='direct' i...

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
alphaNoSignificance level for the confidence band.
shockYesColumn name of the shock / treatment variable.
detailNoPayload 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
nw_lagsNoNewey-West truncation lag. Defaults to ``round(1.5 * horizons)`` per Kilian & Kim (2011) recommendation.
outcomeYesColumn name of the outcome variable y.
auto_lagNoIf ``True`` (the legacy default), also adds ``y_{t-1}`` and ``shock_{t-1}`` as automatic regressors. Set ``False`` for a bare ``y_{t+h} ~ const + shock_t + controls`` specification. These two auto-controls were silent in the pre-1.16 docstring.
controlsNoAdditional regressors taken **verbatim** from ``data``: the column values at time t are used directly, without re-lagging. If you want the lag of a control, lag it yourself before passing it in (e.g. ``df["unemp_lag"] = df["unemp"].shift(1)`` and then ``controls=["unemp_lag"]``). The pre-1.16 behaviour silently re-lagged controls a second time on top of an auto- added ``y_{t-1}``, producing collinear columns and surprising impulse responses; see ``MIGRATION.md`` for context.
horizonsNoNumber of horizons h = 0, 1, ..., H to estimate.
as_handleNoIf 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_pathYesAbsolute 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_idNoOptional 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.
cumulativeNoIf ``True``, return the cumulative response ``y_{t+h} - y_{t-1}``. Default (False) returns ``y_{t+h}`` directly.
endog_orderNoEndogenous variable order used only when ``identification='lpirfs_cholesky'``. Defaults to ``[outcome, shock]``.
data_columnsNoOptional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
data_sample_nNoOptional uniform random subsample size (seed=0, deterministic) — useful on huge panels.
identificationNoShock-identification convention. ``'direct'`` uses the coefficient on the observed ``shock`` variable in each horizon regression. ``'lpirfs_cholesky'`` reproduces ``lpirfs::lp_lin`` with ``lags_endog_lin=1`` and ``shock_type=1``: the variables in ``endog_order`` define the Cholesky ordering, and the reported response is the unit structural shock for ``shock``.direct

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations carry readOnlyHint=true and openWorldHint=false, and the description goes far beyond these by disclosing behavioral nuances: the auto_lag legacy behavior, collinearity failure modes, confidence band explosion, the horizon-0 zero response under Cholesky ordering, and the difference between 'direct' and 'lpirfs_cholesky' identification. This is substantive behavioral context that an agent would otherwise discover only after invoking the tool. 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.

Conciseness5/5

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

The description is long but heavily structured with bolded labels (Validation, Assumptions, Pre-conditions, Failure modes). The core purpose is front-loaded in the very first sentence—no preamble. Every section adds distinct value: assumptions justify the method's validity, pre-conditions prevent incorrect calls, and failure modes suggest concrete parameter fixes. Despite many words, none are redundant given the tool's complexity (16 parameters, nuanced statistical behavior).

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 tool with this many parameters and failure modes, the description covers the necessary bases: statistical assumptions, data prerequisites, identification options, parameter interactions, and troubleshooting steps. An output schema exists (as indicated), so return-value details are not needed in the description. The only minor omission is explicit cross-referencing to sibling tools, but given the depth of internally scattered guidance, the description is effectively complete for operational use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema description coverage, the tool description adds significant meaning beyond the schema: it explains why `auto_lag` may cause collinearity, that `controls` are taken verbatim without re-lagging, how `endog_order` interacts with Cholesky ordering, and the default for `nw_lags` per Kilian & Kim. It also ties parameters to failure modes)Skip, making parameter semantics actionable rather than merely descriptive.

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 opens with a precise verb and resource: 'Estimate impulse responses via Jorda (2005) local projections.' This immediately distinguishes it from sibling estimators like `var`, `irf`, or `direct_method` by naming both the method and the statistical family. The method-specific context (Jorda 2005) anchors the tool's identity.

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?

The description provides rich context on when the tool is appropriate through explicit assumptions (stationarity, conditional exogeneity, adequate Newey-West lags) and detailed pre-conditions (DataFrame structure, Cholesky ordering, sufficient length). It even offers corrective guidance in failure modes (e.g., 'Set auto_lag=False' or 'switch back to identification='direct''). However, it does not explicitly name alternative sibling tools (e.g., `var` or `irf`) or state conditions for choosing them over this tool, so the exclusion is implicit rather than explicit.

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

Deploy Server

Other Tools