Skip to main content
Glama
vikranthviki

Causal Decision Agent

by vikranthviki

rdbwselect

Read-only

Selects optimal bandwidth for regression discontinuity (RD) analysis using MSE- or CER-optimal methods for sharp, fuzzy, and kink designs.

Instructions

Bandwidth selection for local polynomial RD estimation. Validation: certified parity evidence.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cNoRD cutoff value.
pNoPolynomial order for point estimation (1 = local linear).
qNoPolynomial order for bias correction. Default is p + 1.
xYesRunning variable column name.
yYesOutcome variable column name.
allNoIf True, compute and return all ten bandwidth types.
covsNoCovariate column names. When provided, the variance estimates used in bandwidth selection account for covariate adjustment, typically yielding narrower bandwidths.
derivNoDerivative order. 0 = standard RD (jump in level), 1 = regression kink design (change in slope).
fuzzyNoTreatment variable name for fuzzy RD. The MSE being minimised is then the one for the Wald ratio rather than for the reduced form, so every stage of the cascade changes. .. versionchanged:: 1.27.0 This argument was parsed and then discarded: it was never passed to the bandwidth cascade, so ``fuzzy=`` returned the sharp bandwidth while the docstring claimed otherwise. On a two-sided noncompliance replica of the Lee 2008 senate data that is a 9% to 16% error in ``h``. Designs with **one-sided** noncompliance were unaffected, because ``rdbwselect`` itself falls back to the sharp bandwidth there (R's ``perf_comp``) -- which is also why the defect survived: the fixture in the repository was one-sided.
detailNoPayload depth: 'minimal' (~150 tokens) for sub-step calls where only the point estimate is needed; 'standard' (~1K tokens) for diagnostics + coefficient table; 'agent' (~2K tokens, default) adds violations / next_steps / suggested_functions so the LLM can plan its next call without another round-trip.agent
kernelNoKernel function: 'triangular', 'uniform', or 'epanechnikov'.triangular
clusterNoCluster variable name for cluster-robust variance estimation.
bwselectNoBandwidth selection method. One of: - ``'mserd'`` : MSE-optimal common bandwidth (default) - ``'msetwo'`` : MSE-optimal separate left/right bandwidths - ``'msesum'`` : MSE-optimal for the sum of the two intercepts - ``'msecomb1'`` : ``min(mserd, msesum)``, per side - ``'msecomb2'`` : ``median(msetwo, mserd, msesum)``, per side - ``'cerrd'``, ``'certwo'``, ``'cersum'``, ``'cercomb1'``, ``'cercomb2'`` : the CER-optimal counterparts of the above The combination rules are applied to the finished ``h`` and ``b`` of each cascade, element-wise per side -- not stage by stage.mserd
as_handleNoIf true, cache the fitted result on the server and return result_id + result_uri alongside the JSON payload so a subsequent tools/call can chain without re-running.
data_pathYesAbsolute path or URL to a data file. Supported: .csv / .tsv / .txt (delimited), .parquet / .pq, .feather / .arrow, .xlsx / .xls, .dta (Stata), .json / .jsonl. Schemes: file://, s3://, gs://, https://.
result_idNoOptional handle to a previously-fitted result (returned by an earlier call when as_handle=true). Tools that operate on a fitted object accept this in place of re-supplying data_path + columns.
data_columnsNoOptional column projection. Parquet/Feather/Stata loaders honour this for fast partial reads.
data_sample_nNoOptional uniform random subsample size (seed=0, deterministic) — useful on huge panels.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, so the description does not need to establish safety. The phrase 'Validation: certified parity evidence' adds a trust signal about implementation quality, but it does not disclose operational behavior such as what the tool returns, how it handles fuzzy designs, or how the many bandwidth-selection options behave. It is consistent with the annotations, so no contradiction is present.

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 description is extremely short and front-loaded with the core purpose. The second sentence about validation is somewhat tangential to invocation, but it does not add meaningful bloat, so the overall structure remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite a rich schema and output schema, the description is too thin for a tool with 18 parameters and many closely related RD siblings. It does not explain how rdbwselect relates to rdrobust, rdbwhte, rdbwsensitivity, or rdwinselect, and it omits guidance about when a user would prefer this bandwidth-selection tool over alternatives. The validation note does not compensate for this contextual gap.

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 the schema fully documents all 18 parameters. The tool description adds no parameter-level meaning beyond what the schema already provides, matching the baseline score of 3.

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?

The description clearly identifies the tool as 'Bandwidth selection for local polynomial RD estimation,' which names the resource and the statistical context. It is distinguishable from estimation tools like rdrobust, though it does not explicitly distinguish itself from closely related siblings such as rdbwhte or rdbwsensitivity.

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 tool should be used when a bandwidth is needed for local polynomial RD estimation, but it provides no explicit when-to-use or when-not-to-use guidance and names no alternatives. Given the large family of RD sibling tools, this leaves selection among siblings to inference.

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

Deploy Server

Other Tools