Skip to main content
Glama
vikranthviki

Causal Decision Agent

by vikranthviki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

oster_bounds

Read-only

Assess whether unobserved confounders could overturn a treatment effect by computing Oster's bounding coefficient and breakdown delta from short and long regressions, then flag fragile results when delta falls below 1.

Instructions

Oster (2019) sensitivity to selection on unobservables -- computes the bounding coefficient under the assumption that selection on unobservables (proportional to delta x selection on observables) brings the explained variance to r_max. The breakdown delta tells you how strong unobserved selection has to be to overturn your result. Assumptions: Selection on unobservables is proportional (by factor delta) to selection on observables; r_max upper-bounds the explained variance achievable with all confounders included; Linear functional form for y on (treat, controls). Pre-conditions: you have fitted both a short (treatment-only) and long (treatment + controls) regression of y; long-regression R^2 is meaningfully larger than short-regression R^2. Failure modes: breakdown delta < 1.0 (weak unobservables overturn the result) -> The result is fragile; report the breakdown delta alongside the point estimate; r2_long ~ r2_short (controls add no explanatory power) -> Oster's identified set degenerates when long and short R^2 are nearly equal; use sp.evalue or sp.sensemakr instead. Alternatives: sp.evalue, sp.sensemakr, sp.rosenbaum_bounds. Typical minimum N: 200.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yNoOutcome (alternative to passing beta_short/long directly)
alphaNoSignificance level for confidence intervals and tests.
deltaNoRatio of unobserved-to-observed selection (1.0 = equally strong)
r_maxNoHypothetical R^2 from a regression that includes all unobserved confounders; default 1.3*R^2_long
treatNoTreatment indicator or first-treatment-period column.
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
r2_longNor2_long parameter (float).
controlsNoControl-variable column names.
r2_shortNor2_short parameter (float).
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.
beta_longNobeta_long parameter (float).
data_pathNoAbsolute 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.
beta_shortNoShort-regression coefficient; if None, fit from data
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description adds substantial behavioral context: assumptions (proportional selection, r_max bound, linear functional form), pre-conditions, failure modes (breakdown delta < 1.0, r2_long ~ r2_short), and interpretation guidance ('report the breakdown delta'). It goes far beyond annotation-provided safety information, covering the statistical behavior and edge cases without contradicting the read-only hint.

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?

Though long, the description is well-structured into labeled sections (Assumptions, Pre-conditions, Failure modes, Alternatives, Typical minimum N) and front-loaded with the core purpose. Every sentence carries informative content—no filler—making it efficient despite its length.

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?

Given the tool's complexity (16 parameters, output schema present, many siblings), the description covers purpose, assumptions, pre-conditions, failure modes, alternatives, and a minimum N guideline. It tells the agent when to use it, how to interpret the output (breakdown delta), and when to switch tools. The output schema likely details the return values, and the description complements it fully.

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 description coverage is 100%, so the baseline is 3. The description adds conceptual meaning beyond the schema by explaining delta as 'ratio of unobserved-to-observed selection', r_max as 'hypothetical R^2...', and tying beta_short/long and r2_short/long to the pre-condition that a short and long regression have been fitted. This enhances the agent's understanding of how parameters relate to the method.

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 explicitly identifies the tool as Oster (2019) sensitivity analysis for selection on unobservables, computing the bounding coefficient and breakdown delta. It clearly differentiates from siblings by naming alternatives like sp.evalue, sp.sensemakr, and sp.rosenbaum_bounds, so an agent can distinguish it from oster_delta and other sensitivity tools.

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 provides specific pre-conditions ('you have fitted both a short and long regression'), a clear failure mode with an explicit alternative ('use sp.evalue or sp.sensemakr instead'), and lists alternatives explicitly. It tells the agent when to use this tool and when to switch, leaving no ambiguity.

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