StatsPAI

sensitivity_from_result

Read-only

Compute sensitivity analyses from a cached causal fit: E-values, Oster bounds, Cinelli-Hazlett OVB, or an auto dashboard to assess unmeasured confounding.

Instructions

Sensitivity of a cached fit (result_id). 'evalue' (default): E-value from the estimate. 'oster' (delta / R-max) and 'cinelli_hazlett' (OVB bounds) refit OLS of y on treat + controls on the fit's data: from a regress formula (name the term with treat) or passed as y / treat / controls. 'auto': sensitivity dashboard.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "result_id": "<result_id>"
    },
    "name": "sensitivity_from_result"
  }
}

Input Schema

Name	Required	Description	Default
`y`	No	oster / cinelli_hazlett.
`sd`	No	evalue with SMD / MD: the outcome's standard deviation (1 if already standardised).
`treat`	No	Term to bound.
`detail`	No	Payload depth; agent is the fullest.	agent
`method`	No		evalue
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`measure`	No	evalue: scale of the estimate. SMD / MD (a mean difference) need sd; RR / OR / HR are ratios.	SMD
`controls`	No
`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`	Yes	Handle to a fitted causal result.
`data_records`	No	Small inline table as row objects.
`max_output_bytes`	No	Result byte budget (default 262144; 0 = none).
`benchmark_covariate`	No	Cinelli-Hazlett benchmark column (optional).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4.1/5.0

Behavior4/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. The description adds real behavioral context beyond that: 'oster' and 'cinelli_hazlett' silently refit OLS of y on treat plus controls on the fit's data, which tells the agent this is compute-heavy and that the original data must still be reachable. It does not mention cost, limits, or failure modes when the data handle is stale.

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?

Front-loads the core purpose, then maps each enum value to its behavior in tight clauses with no filler. For a tool with 15 parameters and four methods, three sentences is economical, and no sentence merely restates the schema.

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

Completeness4/5

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

An output schema exists, so return values need no explanation, and the description focuses on the method/parameter interactions that are genuinely non-obvious. The remaining gap is the lack of explicit routing guidance against the sibling 'sensitivity' tool for an agent deciding between the two entry points.

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?

With 87% schema coverage the baseline is 3, but the description meaningfully adds relationships the schema cannot express: which parameters matter for which method, that treat/controls may come from a regress formula or be passed explicitly, and that sd is needed only for SMD/MD. This resolves the main ambiguity in a 15-parameter schema where most fields are method-conditional.

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?

States a specific verb and resource: sensitivity analysis of a cached fit identified by result_id, then enumerates the three method families and what each computes. An agent can immediately tell this works on a fitted result handle rather than on raw data or a formula. It does not explicitly contrast itself with the sibling 'sensitivity' tool, so it stops short of a 5.

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?

Use is implied by the required result_id: call this when you already have a cached fit and want E-values or OVB bounds. Method-level guidance ('oster' / 'cinelli_hazlett' refit OLS, 'auto' gives a dashboard) helps pick a path, but there is no explicit statement of when to prefer this over the sibling 'sensitivity' tool or what prerequisites (e.g. needing the underlying data) disqualify a call.

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