StatsPAI

match

Read-only

Estimate treatment effects by pairing treated and control units on covariates with propensity-score, Mahalanobis, CEM, optimal/full, kernel, or radius methods; returns balance diagnostics.

Instructions

Matching estimator dispatcher (ATT by default): nearest-neighbour on the propensity score or Mahalanobis distance, Abadie-Imbens nnmatch, CEM, optimal / full matching, kernel, radius, ... via method=. Returns balance diagnostics. Validation: certified evidence with scoped limitations. Known limitations: greedy nearest-neighbour matching without replacement is order-dependent: the m_order convention can differ across packages and materially moves the estimate (>5x spread on MatchIt::lalonde with Mahalanobis distance). m_order='data' and 'closest' reproduce MatchIt exactly; m_order='farthest' is StatsPAI's own dynamic rule and is not MatchIt-equivalent; bias_correction=True follows a different convention from Matching::Match's BiasAdjust: StatsPAI regresses on the full covariate vector with unweighted OLS over all controls, the reference regresses on the matching variables weighted by match counts, so bias-corrected estimates can differ from it by about 0.1%. The uncorrected estimate and its Abadie-Imbens standard error are exact.

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": {
      "covariates": "<covariates>",
      "treat": "<treat>",
      "y": "<y>"
    },
    "name": "match"
  }
}

Input Schema

Name	Required	Description	Default
`y`	Yes
`treat`	Yes	0/1 treatment.
`detail`	No	Payload depth; agent is the fullest.	agent
`method`	No		nearest
`data_id`	No	Data handle (d_...) from load_data; replaces data_path.
`data_csv`	No	Small inline table as CSV text.
`estimand`	No		ATT
`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.
`covariates`	Yes
`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.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true and openWorldHint=false; the description goes far beyond them by disclosing the order-dependence of greedy nearest-neighbour without replacement, the >5x spread on MatchIt::lalonde, which m_order values reproduce MatchIt versus StatsPAI's own rule, and how bias_correction differs from Matching::Match's BiasAdjust (~0.1%). It also states that the uncorrected estimate and Abadie-Imbens SE are exact, which is exactly the kind of reliability context an agent needs.

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 and default are front-loaded in the first clause, and the limitations follow in a logical block. It is dense but nearly every clause carries usable information; the precise figures (>5x spread, ~0.1%) verge on over-detail but support the stated caveats rather than padding.

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?

With 13 parameters, high complexity, and an output schema (so return values need no explanation), the description covers the dispatch surface and the main statistical pitfalls well. It leaves gaps around data-source selection and the as_handle/result_id caching workflow, but those are partly documented in the schema itself.

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 a middling 69%, and the description adds real meaning for method= (mapping each enum value to a matching family) and confirms the ATT default. However, it spends most of its parameter discussion on m_order and bias_correction, which do not appear in the input schema, and it says nothing about covariates/treat/y or the data_id/data_path/data_csv/data_records precedence, so the added meaning is partly off-target.

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?

The description names a specific verb and resource ('Matching estimator dispatcher') and enumerates the concrete matching families it dispatches to (nearest-neighbour on propensity score or Mahalanobis, Abadie-Imbens nnmatch, CEM, optimal/full, kernel, radius) plus the default estimand (ATT). An agent can distinguish this from estimation siblings such as did, iv, or ebalance without opening the schema.

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 statement of when to choose matching over the other causal estimators in the sibling set, nor any when-not condition or named alternative. The only routing guidance is internal ('via method='), which tells the agent how to pick a matching variant but not whether matching is the right tool.

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