interference

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

Annotations declare readOnlyHint=true and the description does not contradict it. The description adds useful behavioral context with validation evidence tiers, assumptions, and failure modes. It leaves some operational details such as response payload behavior to the schema and detail parameter, but that is acceptable given the annotation coverage.

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 densely informative, opening with a one-line purpose before enumerating designs, assumptions, and failure modes. The trailing ellipsis suggests possible truncation, and some content overlaps with the structured schema, but for a complex dispatcher tool the length is mostly justified.

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 complexity, 7 parameters, and many design families, the description is highly complete: it covers assumptions, pre-conditions, failure modes, validation, and points to a dedicated guide. Since an output schema is present, detailed return-value documentation is not required in the description. The only notable omission is sibling differentiation, which is more of a usage-guidelines concern.

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?

The input schema has 100% description coverage, so the baseline is 3, but the description adds meaning by naming concrete design values ('partial', 'network_exposure', 'peer_effects', etc.) and noting that kwargs pass through to the target function. It does not re-document every parameter because the schema already handles those, but the design enumeration goes beyond the schema.

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 a specific verb+resource: a 'Unified interference / spillover dispatcher' that selects among named estimator families. It provides rich detail on what designs are available, but it does not explicitly differentiate itself from closely related sibling tools like network_exposure or cluster_cross_interference.

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 gives concrete pre-conditions (clustered data or network/adjacency matrix, treatment variation, >=30 clusters) and assumptions (SUTVA modulo spillover, correctly specified exposure). It also points to the sp.interference_family guide and recommends wild cluster bootstrap when clusters are few. However, it does not explicitly state when to use this unified dispatcher versus sibling alternatives.

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