Causal Decision Agent

Overview Schema Source Related Servers Discussions Admin

anderson_rubin_test

Read-only

Test hypotheses on an endogenous coefficient in instrumental variables regression, with inference that remains valid when instruments are weak. Obtain reliable p-values and confidence sets for causal parameters.

Instructions

Anderson-Rubin (1949) test -- size-correct under weak instruments. Validation: certified parity evidence.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`y`	Yes	Outcome variable.
`h0`	No	Null hypothesis value for the endogenous coefficient.
`exog`	No	Included exogenous controls.
`vcov`	No	Variance estimator used for the Olea-Pflueger effective F reported alongside AR.	HC1
`alpha`	No	Significance level.
`endog`	Yes	Endogenous regressor (single).
`absorb`	No	High-dimensional fixed effects to partial out of ``y``, the endogenous regressor, the instruments and the controls before the test -- the same residualisation ``sp.iv(absorb=...)`` performs.
`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
`cluster`	No	Cluster the AR statistic. Switches from the homoskedastic F-form to the (multiway) cluster-robust quadratic form ``(Z'e)' Omega^-1 (Z'e)`` with ``Omega`` the cluster-sum variance of the moment vector, referred to ``F(k_z, G-1)``. Without this, a panel AR test over-rejects exactly as a homoskedastic t-test
`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.
`instruments`	Yes	Excluded instruments.
`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

B3.3/5.0

Behavior3/5

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

The description adds that the test is size-correct under weak instruments and claims 'certified parity evidence' for validation, while readOnlyHint=true already covers the absence of side effects. It does not describe the returned statistic or decision rule, but the output schema is available and the safety profile is carried by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The text is short and front-loads the main identification ('Anderson-Rubin test ... size-correct under weak instruments'). However, 'Validation: certified parity evidence' is a cryptic fragment that does little to help an agent select or invoke the tool, and the overall description is under-sized relative to the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Between the detailed schema and the one-line purpose, a knowledgeable agent can assemble the required inputs (data_path, y, endog, instruments) and infer this is a weak-instrument-robust IV test. Missing explicit guidance on when to prefer it over siblings such as 'anderson_rubin_ci' or 'ivreg' leaves clear gaps, but they are not fatal given the schema richness.

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 description coverage is 100%, so all 15 parameters are already documented in the input schema, including details like h0's null hypothesis value and cluster's robust quadratic form. The description itself adds no parameter-level meaning, so it sits at the baseline for schema-covered tools.

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 names the exact procedure ('Anderson-Rubin (1949) test') and gives a meaningful property ('size-correct under weak instruments'), so an agent can identify it as a weak-instrument-robust IV hypothesis test. It does not explicitly contrast it with the sibling 'anderson_rubin_ci' or other IV estimators, but the core purpose is reasonably clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'size-correct under weak instruments' is an implicit usage signal: use this test when weak-instrument robustness matters. However, it does not say when not to use it, name alternatives such as 'anderson_rubin_ci' or 'ivreg', or state prerequisites, so the guidance remains implied 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