wild_cluster_bootstrap

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

Annotations already mark the tool as read-only, and the description goes well beyond that by disclosing runtime cost, finite-sample validity assumptions (G >= 5), preconditions on the dataset shape, and known failure modes. It also explains the bootstrap re-sampling behavior and the trade-off being made, so an agent can predict behavior and plan around cost.

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 dense but well structured: purpose first, then explicit do-not-use guidance, cost, assumptions, preconditions, and failure modes. Each section earns its place and is front-loaded with the information most important for selection and invocation. The length is justified by the statistical complexity of the tool.

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?

Given the tool's statistical complexity, the large parameter set, and the rich schema, the description covers what an agent needs to select and invoke it correctly: when to use it, when not to, cost properties, assumptions, preconditions, and failure modes. The output schema exists, so return-value explanation is unnecessary, and the description need not repeat what structured fields already provide.

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 schema already documents each parameter. The description adds meaningful semantics beyond that, including the relationship between n_boot and runtime, the fact that test_var defaults to the first column of x, and the cluster-level exchangeability assumption behind Rademacher weights. It does not redundantly re-specify every parameter, but provides enough extra meaning to support correct configuration.

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 opens by naming the exact method (Cameron-Gelbach-Miller 2008 wild cluster bootstrap) and its intended use case (cluster-robust inference with few clusters, G < 30). It also differentiates from alternatives by saying ordinary CRV1 is the better choice for large clusters and that multi-way clustering should route to subcluster_wild_bootstrap. This makes the tool's scope immediately clear to an agent.

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 explicitly states when to use this tool (few clusters, G < 30), when not to use it (large clusters, say > 50, use ordinary CRV1), and names an alternative for unsupported cases (subcluster_wild_bootstrap for multi-way clustering). It also gives practical guidance such as not raising n_boot inside an outer search loop, which is exactly the kind of operational direction an agent needs.

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