StatsPAI

rdrobust

Read-only

Estimates sharp or fuzzy regression-discontinuity effects with robust bias-corrected confidence intervals, including IV-style fuzzy RD.

Instructions

Sharp or fuzzy regression-discontinuity with robust bias-corrected CIs (Calonico-Cattaneo-Titiunik 2014). Use fuzzy= for IV-style fuzzy RD. Validation: certified evidence with scoped limitations. Known limitations: the weighted rbc bootstrap is not supported -- passing weights= with bootstrap='rbc' raises MethodIncompatibility; R-parity certification applies only to the configurations enumerated by sp.validation_scope(function='rdrobust') -- the default native mserd / triangular / p=1 / nn path (Track A 06), a manual bandwidth, and the weighted rows -- other selectors, kernels and vce choices are pinned for sp.rdbwselect or not at all for this entry point.

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

Input Schema

Name	Required	Description	Default
`c`	No	Cutoff value.
`x`	Yes	Running variable column.
`y`	Yes
`fuzzy`	No	Treatment column for fuzzy RD (optional).
`detail`	No	Payload depth; agent is the fullest.	agent
`kernel`	No		triangular
`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.
`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

Behavior4/5

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

Annotations already declare readOnlyHint and closed-world, so the description earns credit for adding a concrete failure mode (weights= with bootstrap='rbc' raises MethodIncompatibility) and for scoping R-parity certification via sp.validation_scope. It does not describe return contents, but an output schema exists to carry that.

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?

Front-loaded with method and citation, then the fuzzy note, then limitations — a sensible ordering. The validation-scope sentence is dense and enumerates configurations at length, but each clause carries certification information the agent would otherwise guess at.

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?

Given 13 parameters, an output schema, and existing annotations, the description covers the estimator, the fuzzy variant, the main incompatibility, and the certified configuration envelope. Data-source parameters and the caching workflow are left to the schema, which is defensible at 85% coverage.

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 85%, so most parameters (c, kernel, detail, data handles, max_output_bytes) are already documented in structured fields. The description adds meaning only for fuzzy=, and says nothing extra about the default mserd/triangular/p=1 path parameters or the as_handle/result_id lifecycle.

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?

Specific verb and resource: 'Sharp or fuzzy regression-discontinuity with robust bias-corrected CIs (Calonico-Cattaneo-Titiunik 2014)', with fuzzy= explicitly named for IV-style fuzzy RD. An agent can distinguish this estimator from sibling entry points 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 Guidelines3/5

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

The description implies the fuzzy-RD use case and redirects non-default selectors, kernels and vce choices to sp.rdbwselect, which is real routing guidance. It never explicitly says when to use this rather than pipeline_rd, check_identification, or detect_design, so selection between entry points is left to inference.

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