Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

liml

Read-only

Estimate causal effects with instrumental variables using limited information maximum likelihood, addressing weak instruments and overidentification for reliable treatment-effect inference.

Instructions

Limited Information Maximum Likelihood (LIML) estimator. Validation: certified parity evidence. Assumptions: Relevance: instruments predict the endogenous regressor (first-stage F >= 10 rule of thumb); Exclusion: instruments affect outcome only through the endogenous regressor; Monotonicity (for LATE interpretation under heterogeneous effects). Pre-conditions: formula includes the (endog ~ instruments) parenthesised block; at least as many instruments as endogenous regressors (order condition); instruments are not themselves endogenous in the outcome equation. Failure modes: First-stage F < 10 (Stock-Yogo 5% bias) -> Use weak-IV-robust inference (Anderson-Rubin) or LIML; Over-identification test rejects (sp.estat 'overid') -> At least one instrument is invalid; drop instruments or switch to just-identified LIML; Hausman endogeneity test fails to reject -> OLS may be consistent and more efficient; report both. Alternatives: sp.deepiv, sp.bartik, sp.proximal, sp.regress. Typical minimum N: 100.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`y`	No	Outcome variable.
`z`	No	Excluded instruments.
`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
`fuller`	No	Fuller's constant (typically 1 or 4). If None, pure LIML.
`robust`	No	Robust standard-error or covariance estimator option.	nonrobust
`x_exog`	No	Exogenous regressors (included instruments).
`cluster`	No	Cluster identifier column for clustered standard errors.
`formula`	No	Model formula using patsy/R-style syntax.
`x_endog`	No	Endogenous regressors.
`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`	No	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.
`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.

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

Behavior5/5

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

With annotations only declaring readOnlyHint=true and openWorldHint=false, the description carries the behavioral burden and goes well beyond it: it discloses the maintained assumptions, testable pre-conditions, concrete failure diagnostics, and remedy instructions. The readOnlyHint is consistent with a pure estimator that produces fitted results. No contradictions.

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 dense but purposefully organized into labeled blocks (Validation, Assumptions, Pre-conditions, Failure modes, Alternatives, Typical minimum N), with the core estimator named first. Every sentence carries operational value (no filler), though the sp.*-prefixed names ('sp.estat', 'sp.deepiv') that don't exactly match sibling tool names (deepiv, estat, bartik exist; sp. variants do not) introduce minor routing confusion and slightly inflate length, keeping it below a perfect 5.

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 15-parameter econometric estimator with an output schema, the description is essentially complete: assumptions, identification pre-conditions, ordered failure modes with remedies, alternative tools, and a typical minimum N are all present. The output schema and rich per-parameter schema descriptions handle return values and payload details, so nothing an agent needs to decide whether and how to call this 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%, so the schema already documents all 15 parameters, and the high-coverage baseline is 3. The description adds genuine semantic value for key parameters not in the schema: the formula parameter gains an explicit syntax requirement (compound formula 'formula includes the (endog ~ instruments) parenthesised block'), and the Z/x_endog relationship gets the order condition. alpha, detail, robust, cluster, as_handle, result_id, and the data-loading parameters receive no addenda, but the schema covers them sufficiently, so 4 is appropriate.

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 the exact estimator name ('Limited Information Maximum Likelihood (LIML) estimator'), states a clear validation status ('certified parity evidence'), and elaborates with assumptions, pre-conditions, and failure modes. It distinguishes the tool from related IV estimators in the sibling list (iv, ivreg, auto_iv) by specifying its identification requirements and when LIML is preferred over alternatives.

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 'Failure modes' section is effectively an explicit routing rule: first-stage F < 10 -> use Anderson-Rubin or LIML; over-identification rejection -> drop instruments; Hausman failure -> OLS may be better. Alternatives are named explicitly (sp.deepiv, sp.bartik, sp.proximal, sp.regress, sp.estat), giving the agent concrete when-to-use/when-to-switch guidance. This is textbook usage guidance beyond a bare statement of what the tool does.

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

Deploy Server