rd_interference

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

Beyond the readOnlyHint annotation, the description discloses important behavioral context: assumptions that must hold, failure modes such as manipulation of the running variable and bandwidth sensitivity, recommended remedies, typical minimum N, and alternative tools. This gives the agent a clear picture of the tool's limitations and data requirements without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense, covering assumptions, preconditions, failure modes, alternatives, and sample-size guidance. Every section earns its place for such a complex econometric tool; it is front-loaded with the method and citation. It could be slightly tightened, but overall it is well organized.

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

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

For a complex RDD tool with 13 parameters and an output schema, the description is remarkably complete: it states the identifying assumptions, data preconditions, common failure modes with concrete remedies, alternative estimators, and a minimum N heuristic. Nothing essential is missing for an agent to decide whether to call this tool and how to interpret its role.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds useful conceptual context for parameters like running variable, cutoff, bandwidth, and neighbour_running, including advice to use data-driven MSE-optimal bandwidth and warning about density jumps at the cutoff. This goes beyond the schema but does not fully map every parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a sharp RDD estimator extended to network interference, citing a specific method and distinguishing it from the many non-interference RDD siblings. It lacks an explicit verb like 'estimates' or 'fits', and the 'Sharp RDD' label is slightly at odds with the later mention of fuzzy designs, so it is not a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides explicit pre-conditions, assumptions, and failure modes, and names alternatives (sp.rdrobust, sp.rdrandinf, sp.rdbwselect). It does not fully spell out the exact conditions under which to choose each alternative, but the preconditions and failure-mode guidance effectively tell an agent when this tool is appropriate and when it is not.

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