StatsPAI

audit_result

Read-only

Review a fitted result against expected robustness checks, see passed, failed, missing, or not-applicable statuses, and get suggested functions for missing checks.

Instructions

Reviewer-grade audit of a fitted result (result_id from an as_handle=true call): every robustness check the literature expects for the design, with status 'passed|failed|missing|not_applicable' and a suggest_function for each missing one. not_applicable checks (an overid test on a just-identified IV) carry a 'reason' and are left out of n_total.

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": "audit_result"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	Payload depth; agent is the fullest.	agent
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`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 returned by an earlier estimator call. Must be in the server result cache (LRU-evicted; refit if missing).
`data_records`	No	Small inline table as row objects.
`max_output_bytes`	No	Result byte budget (default 262144; 0 = none).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A3.5/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 safety is covered. The description's added content is mostly output semantics — the status vocabulary, suggest_function for missing checks, and the rule that not_applicable checks carry a reason and are excluded from n_total. That is useful nuance, but since an output schema exists, restating return values is largely duplicative and the description says nothing about cost, whether checks require refitting, or what data is needed.

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?

Two sentences, front-loaded with the core action and followed by the status/exception rules. Dense but each clause carries information; the parenthetical just-identified IV example earns its place as a concrete illustration.

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?

For an eight-parameter, read-only tool with a full schema, complete parameter coverage, annotations, and an output schema, the description covers the essentials of what the audit does and how results are classified. The remaining gap is not explaining why data_id/data_path are accepted and whether a refit occurs, which an agent choosing arguments would want to know.

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 eight parameters are already documented, including result_id caching/LRU caveats and the detail enum. The description adds only the 'as_handle=true' provenance hint for result_id, which is marginal. The presence of data_id/data_path/data_csv parameters hints the audit may need the underlying data, but the description never explains that relationship.

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+resource: a reviewer-grade audit of a fitted result, enumerating robustness checks with passed/failed/missing/not_applicable statuses. The scope is pinned down by 'result_id from an as_handle=true call', so an agent knows exactly what object is being audited. It does not explicitly differentiate itself from the sibling 'audit' or 'check_identification', 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?

The prerequisite is implied and partly stated: the result_id must come from an as_handle=true call. There is no explicit when-to-use vs when-not guidance, and no routing to alternatives such as check_identification or honest_did_from_result for narrower diagnostics. Usage is inferable (run after fitting) but not spelled out.

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