StatsPAI

cross_validate

Read-only

Cross-check one estimand across independent engines and report AGREE, PARTIAL, DISAGREE, or INSUFFICIENT so estimates are trusted only when reproduced by two or more implementations.

Instructions

Cross-validate ONE estimand across INDEPENDENT engines (StatsPAI, pyfixest, linearmodels, DoubleML, R's fixest, Stata) and report whether they agree (AGREE / PARTIAL / DISAGREE / INSUFFICIENT). Use this to honour the cross-package reproducibility rule: trust a number only when >=2 independent implementations reproduce it. Needs a data_path.

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": {
      "estimand": "<estimand>"
    },
    "name": "cross_validate"
  }
}

Input Schema

Name	Required	Description	Default
`g`	No	DiD only: cohort / first-treatment period (0 = never treated).
`i`	No	DiD only: unit-id column.
`t`	No	DiD only: time column.
`y`	No	Outcome column.
`vcov`	No
`endog`	No	Endogenous regressors (IV).
`detail`	No	Payload depth; agent is the fullest.	agent
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`engines`	No	Engines to run, e.g. ['statspai','R::fixest','pyfixest','Stata']. Omit for 'auto' (all installed + applicable).
`formula`	No	fixest-style 'y ~ x \| fe \| endog ~ z'.
`data_csv`	No	Small inline table as CSV text.
`estimand`	Yes	Model family to fit in every engine.
`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	Focal regressor (reconciled coefficient).
`covariates`	No
`instruments`	No
`data_records`	No	Small inline table as row objects.
`fixed_effects`	No
`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.8/5.0

Behavior3/5

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

Annotations already declare this a read-only, non-open-world operation, so the description only needs to add context. It does add the agreement taxonomy and the two-engine trust threshold, but the closing claim 'Needs a data_path' is narrower than the schema, which also accepts data_id, data_csv, data_records, or a result_id handle.

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?

Three tight sentences, front-loaded with the core action before the routing rule. The trailing 'Needs a data_path' is the one weak clause, since it overstates a requirement the schema treats as optional alongside handle-based alternatives.

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 a 21-parameter tool with an output schema and strong annotation coverage, the description covers purpose and output categories adequately. It does not explain that engines default to auto-detect or how the agreement verdicts are computed, which would help an agent set the 21 parameters confidently.

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 documents nearly every field, and the description adds no field-level meaning beyond the data_path remark. Baseline of 3 applies when the input schema does the heavy lifting.

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?

States a specific verb and resource - cross-validate ONE estimand across independent named engines - and says exactly what it returns (AGREE / PARTIAL / DISAGREE / INSUFFICIENT). The 'ONE estimand' and '>=2 independent implementations' framing clearly separates it from the single-engine siblings like feols, iv, and dml.

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 decision rule for when to reach for it: trust a number only when at least two independent implementations reproduce it. That is real when-to-use guidance, but no when-not or named alternative is offered for the case where only one engine is available.

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