StatsPAI

check_identification

Read-only

Run pre-estimation identification diagnostics to detect design problems—bad controls, overlap, cohort sizes, weak IV first-stage F, and clustering—before fitting any estimator.

Instructions

Design-level identification diagnostics: bad controls, overlap, cohort sizes, IV first-stage F, clustering. Run BEFORE fitting any estimator to surface design problems.

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": {
      "y": "<y>"
    },
    "name": "check_identification"
  }
}

Input Schema

Name	Required	Description	Default
`y`	Yes
`id`	No
`time`	No
`cohort`	No
`design`	No
`detail`	No	Payload depth; agent is the fullest.	agent
`strict`	No	Raise IdentificationError on BLOCKERS.
`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`	No	Handle of an earlier fit made with as_handle=true.
`treatment`	No
`covariates`	No
`instrument`	No
`running_var`	No
`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.7/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 adds real behavioral value by saying the tool inspects design properties pre-fit rather than estimating, but it says nothing about what happens on failure beyond the schema's own strict/IdentificationError note, nor about data prerequisites or runtime cost.

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?

Two short sentences, front-loaded with what it checks and followed by the sequencing instruction. Every clause carries information; there is no filler.

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?

For an 18-parameter tool with an output schema, the description is thin: it never mentions how data is supplied (data_id, data_csv, data_path, data_records, result_id), what the design enum choices imply, or which parameters are required. The existence of an output schema excuses explaining return values, but the input-side complexity is under-addressed.

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 coverage is 50%, and the description indirectly maps several parameters to checks (instrument to first-stage F, cohort to cohort sizes, clustering), which is genuine added meaning. However, 18 parameters include many undocumented ones (design enum, treatment, running_var, the four data-input handles, detail, max_output_bytes) that the description never touches, so it only partially compensates for the coverage gap.

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 resource (design-level identification diagnostics) and enumerates concrete checks: bad controls, overlap, cohort sizes, IV first-stage F, clustering. That is far more informative than the tool name alone and lets an agent see it is a diagnostic pass rather than an estimator fit. It does not explicitly differentiate itself from near-siblings such as preflight or detect_design, which keeps it from 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 Guidelines4/5

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

Gives an explicit temporal directive: run BEFORE fitting any estimator, with a stated rationale (surface design problems). That is a clear usage context. It stops short of stating when not to use it or naming an alternative for post-fit checks, so it does not reach the top band.

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