StatsPAI

sensitivity

Read-only

Test how strong an unobserved confounder must be to overturn a causal estimate using Oster, Cinelli-Hazlett, and E-value bounds.

Instructions

Unified sensitivity analysis for observational causal estimates -- supports Oster (2019) delta/R-max, Cinelli-Hazlett (2020) omitted-variable bias bounds, and E-values (VanderWeele-Ding 2017). Tells the agent how strong an unobserved confounder would have to be to overturn the result. Validation: certified parity evidence.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sensitivity"
  }
}

Input Schema

Name	Required	Description	Default
`y`	No	Outcome column (lets the bound recompute covariate R^2 from data alongside the result).
`treat`	No	Treatment column.
`detail`	No	Payload depth; agent is the fullest.	agent
`result`	No	Fitted regression / causal result handle (result_id from a prior fit run with as_handle=true). Required -- the bounds are computed relative to this estimate.
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`rho_max`	No	Oster R_max for the Oster bound. Default: min(1, 1.3 x R^2 of the controlled regression).
`controls`	No	Observed control columns.
`data_csv`	No	Small inline table as CSV text.
`as_handle`	No	Cache the fit and return its result_id.
`data_path`	No	Absolute path of a data file on the server.
`result_id`	No	Handle of an earlier fit made with as_handle=true.
`data_records`	No	Small inline table as row objects.
`include_oster`	No
`max_output_bytes`	No	Result byte budget (default 262144; 0 = none).
`include_rosenbaum`	No
`include_sensemakr`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description only needs to add computation context, which it does by naming the three estimators and their citations. What it omits is cost/behavior: whether all three analyses run by default (the include_* defaults suggest yes), how expensive that is, or what happens when the referenced result handle is missing. The trailing 'Validation: certified parity evidence' is an unsupported claim rather than usable behavioral information.

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 purpose is front-loaded in a single dense opening sentence, followed by a plain-language payoff line, so an agent gets the gist immediately. The final sentence 'Validation: certified parity evidence' is unexplained filler that adds no actionable information. Overall tight for the amount of method detail conveyed.

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?

An output schema exists and the annotations cover safety, so return-format explanation is rightly omitted. However, with 16 parameters and zero declared required, the definition should clarify the input-mode choice and note that 'result' is effectively mandatory, since the description says it is 'Required' while the schema's required array is empty — an inconsistency the description does not resolve. The include_oster/include_rosenbaum/include_sensemakr flags are never mentioned, so an agent cannot tell that output composition is configurable.

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 81%, so the schema already carries most parameter meaning and a baseline of 3 is appropriate. The description adds framing for what the tool computes but contributes no semantics for how the four alternative data inputs (data_path, data_id, data_csv, data_records) relate or which takes precedence. It does not explain the relationship between the 'result' and 'result_id' parameters, both of which appear in the schema.

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 a specific verb and resource ('Unified sensitivity analysis for observational causal estimates') and enumerates the three concrete methods it implements (Oster delta/R-max, Cinelli-Hazlett bounds, E-values). The lay explanation 'how strong an unobserved confounder would have to be to overturn the result' makes the output intent unambiguous. It stops short of 5 because it never distinguishes itself from the sibling 'sensitivity_from_result', which by name sounds like an overlapping path to the same result.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not statement; the closest thing to guidance is that 'result' is described as coming from a prior fit run with as_handle=true, which is a prerequisite, not a routing rule. Given a near-identically named sibling ('sensitivity_from_result'), the definition leaves the agent to guess which entry point to pick. No mention of when sensitivity analysis is or isn't appropriate (e.g., only for observational designs, or required prior steps).

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