Validate deflated Sharpe

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

Annotations provide readOnlyHint=false and destructiveHint=false but little else, so the description carries some burden. It adds a genuinely useful interpretive caveat — the deflated Sharpe or overfitting probability 'is not admission to anything and is not a forecast' — which prevents an agent from over-weighting the result. However, it does not disclose behavior on invalid input (e.g., what happens when both input modes are sent) or how results are surfaced beyond the two hinted values.

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?

Three sentences, each earning its place: purpose, input constraint, and interpretive caveat. There is no word waste, but the first sentence is grammatically tangled, forcing multiple re-reads. The structure is reasonable; the execution of the opening sentence drags the score below a clean 4.

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?

With no output schema, the description must carry the return-value burden, and it partially does — mentioning a 0-to-1 probability and the luck-only Sharpe. For an 8-parameter statistical validation tool with no side effects, this plus the annotated schema is adequate. Missing: the shape of the result (single object? multiple fields?), and the distinction from adjacent validators, which is relevant given sibling context.

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 coverage is 100%, so the baseline is 3, and the schema's returns field already notes it 'replaces the Sharpe, observations, skew and kurtosis fields.' The description adds genuine value on top: it frames the seven numeric statistics as one cohesive input mode, introduces the 'not both' mutual-exclusivity rule, and clarifies the returns-array alternative — a critical calling constraint that the schema leaves implicit across its optional fields.

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 core purpose is discernible — determining whether an observed Sharpe survives the number of variants tried (deflated Sharpe / multiple-testing correction). However, the phrasing is garbled: 'probabilistic and deflated Sharpe (0 to 1) and the Sharpe luck alone would reach' is grammatically broken and forces the agent to infer that the output is a probability plus a luck-only Sharpe threshold. It does identify a distinct resource among the validator siblings, but not clearly enough for a confident 4.

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 offers one real usage rule — 'Send the seven statistics or a return series, not both' — which governs input mode rather than tool selection. Against an environment with 13 siblings including validate_overfitting, validate_luck_trials, and validate_haircut_sharpe, there is zero guidance on when to choose this over those alternatives. No exclusions, no conditions, no named alternative tools.

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