Canli Validation

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

Annotations declare readOnlyHint=false and openWorldHint=true, and the description adds context consistent with that: each check returns the matching validator's result with its own receipt, and only one validation runs per check. It also discloses an interpretation limit ('not admission to anything and is not a forecast'), which is genuine behavioral guidance. It stops short of saying what is written or persisted, hence 4 rather than 5.

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, front-loaded with the aggregate purpose before the input and caveat details. It is dense and one clause ('each the matching validator's result with its own receipt') is grammatically awkward, but no sentence is filler or repetition.

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?

An output schema exists, so return values need not be explained, and with 11 parameters at full schema coverage the description's job is mostly orientation. It covers the aggregation scope, the file-input alternative, the one-check-per-validation constraint, and the interpretation caveat, leaving only minor gaps such as failure behavior when returns_file is unreadable.

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 real meaning on top of it: returns_file is 'not on the hosted endpoint,' so the agent learns the path is resolved on the local machine, and it clarifies that supplying variants is what adds the overfitting check. That is useful beyond the schema text.

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?

States a specific verb and resource ('One-call audit of a strategy's returns') and enumerates exactly what it computes: deflated Sharpe, minimum track record, and, when variants are supplied, the probability of backtest overfitting. This maps directly onto the sibling validators (validate_deflated_sharpe, validate_track_record, validate_overfitting) so an agent can tell it apart from them without opening a schema.

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?

Explicitly routes between alternatives: 'Prefer it to calling the validators one by one; one validation per check' and 'Point returns_file at the backtest's CSV or JSON instead of pasting long series.' Both the aggregate-vs-individual choice and the file-vs-inline choice are named with their selecting conditions.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the response ordering (newest first), returned fields, the source SHA-256 for provenance, and the strong caveat that values are accounting figures rather than returns. It omits auth/rate-limit behavior, so not a 5.

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?

Front-loaded with the core purpose, but the tail is padded with stacked disclaimers ('not market prices, returns, an investment recommendation, or ALPHAC performance' and a separate return-validation sentence). The intended meaning survives, but several clauses could be trimmed without loss.

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?

An output schema exists, so return values needn't be enumerated, and the description still covers the conditional response shape, ordering, provenance hash, and scope limits. For a read-only, 4-param tool this is near-complete; only auth/rate-limit context is absent.

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 real conditional semantics not in the schema: omitting 'concept' returns the list of available histories, while supplying it returns observations — behavior the schema names alone don't convey.

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?

States a specific verb and resource ('SEC-reported financial history for one company ... by cik or ticker') and bounds the domain clearly (accounting reference, not market prices/returns). It does not name a sibling tool directly, but it points at external products and the validation API, so an agent can still separate it from the validate_* family.

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?

Gives conditional usage ('without a concept, the histories available; with one, observations newest first') and explicit when-not routing ('For point-in-time values use canli-fundamentals-mcp', 'Validate a separately constructed return series with the validation API; accounting values are not returns'). Alternatives are named, but they are mostly outside the sibling set, so it stops short of a full routing rule.

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

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

Annotations only establish that this is an open-world, non-idempotent, non-destructive write. The description adds substantial operational context the agent cannot get elsewhere: per-day key and validation quotas, request and revocation byte limits, and series/matrix cardinality caps. This is exactly the kind of rate-limit and quota disclosure that earns full credit.

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?

Front-loaded with the purpose and the 'rarely needed' caveat before the quota list, so the most decision-relevant information comes first. The quota sentence is long and includes limits for adjacent endpoints (key revocation, series, matrices) that are not this tool's concern, which is mild scope creep.

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?

An output schema exists, so return-value detail is not required, and the description fully covers prerequisites, when to skip the call, and quotas. It never says whether calling it twice produces the same or additional keys, though idempotentHint=false partially covers that.

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% and there is a single optional 'label' parameter already documented in the schema. The description adds no meaning beyond it (no naming conventions, uniqueness, or default behavior), so the baseline 3 applies.

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?

States a specific verb and resource ('Issue a free validation key for this session'), which immediately distinguishes it from the validate_* siblings that consume such keys. The word 'free' and 'for this session' scopes the artifact being produced.

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?

Explicitly says the tool is 'rarely needed' and names the conditions under which it is unnecessary: the first validation self-issues a key unless CANLI_KEY or local mode is set, and read tools need none. That is genuine when-not-to-use guidance, not just a when.

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

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

Annotations already mark this readOnly, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: no key required, the receipt is content-hashed and reproducible from the open-source core, and it is Ed25519-signed by a key at a published well-known URL. Missing only error/absence behavior for an unknown id.

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 tightly packed sentences, front-loaded with the core action and immediately followed by the sibling disambiguation and trust model. No filler sentences.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. For a single-param read tool, the description supplies the routing, auth, and verification-model context an agent needs to invoke it correctly.

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% and the single 'id' param is fully documented in the schema (pattern plus provenance note). The description adds only the phrase 'by receipt id', so it neither compensates nor detracts; baseline 3 is appropriate.

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?

States a specific verb (Fetch) and resource (a stored verdict by receipt id) plus the intent (to re-read it), and explicitly differentiates itself from the sibling verify_receipt. An agent can distinguish it from the validate_* and verify_* tools without opening a schema.

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?

It routes the agent: use this to re-read a stored receipt, use verify_receipt to check genuineness. It also states 'No key', clarifying the auth posture for invocation. It stops short of enumerating when-not-to-use (e.g., what to do if the id is unknown or the receipt is missing).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new context: 'No key' (no authentication required) and that quotas are returned, plus a caveat about the scope of the verdict.

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 purpose and usage trigger are front-loaded well, but one of the three sentences is off-topic for a status endpoint and does not earn its place, diluting an otherwise tight definition.

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?

An output schema exists, so return values need not be described, and no input params need documenting. The remaining gap is that the trailing 'series as submitted' caveat is irrelevant to a service-status call and could mislead an agent about what this tool reports.

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?

Zero parameters, so the baseline of 4 applies; there are no inputs whose semantics need explaining.

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 opening clause ('Whether the validation API is up, with its quotas') states a specific resource and check, which distinguishes it from the validate_* siblings. However, the trailing sentences about 'the series exactly as submitted' and what 'the service never saw' belong to a validation-verdict tool, not a health check, and muddy what the tool actually is.

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?

'check after a timeout before resubmitting' gives an explicit trigger condition for calling it, which is exactly the kind of context an agent needs. It does not name sibling alternatives, but the trigger is clear enough to route correctly.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, which is an odd profile for what the description frames as a pure planning calculation; the description does not reconcile that (no side effects, no persisted state, no external calls disclosed). It does add genuine interpretive context that outputs are not admissions or forecasts, which goes beyond the annotations. With annotations already present, a 3 is appropriate.

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?

Purpose and the sibling handoff are front-loaded, which is good, but the opening is a single long clause-stacked sentence that is hard to parse on first read. The closing sentence about thresholds not being admission is useful but borders on editorial and is not clearly tied to what this tool returns.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, planning-time usage, and the handoff tool. For a stateless computation with fully documented parameters, that is close to sufficient; only the reconciliation of the readOnlyHint=false annotation is missing.

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% and all three parameters are documented in the schema with bounds and defaults. The description restates backtest_years ('with backtest_years, the most trials those years allow') without adding syntax or format meaning beyond the schema, so the baseline of 3 applies.

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 names a specific quantity (minimum backtest length in years) and the condition under which it holds (best of N independent trials not reaching target Sharpe by luck), which is far more specific than the title alone. It is somewhat syntactically dense and reads like a textbook definition rather than a plain 'what this does', and it does not directly contrast itself with siblings like validate_luck_trials.

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?

It states the setting explicitly ('For planning a search') and names the alternative with the condition that selects it ('once it has a result, use validate_deflated_sharpe'). It also adds a when-not caveat: a deflated Sharpe or overfitting probability past any threshold is not admission to anything, so it should not be used as a decision gate.

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

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

Beyond the annotations, the description discloses meaningful scope limits: the verdict applies only to the series as submitted and the service never inspected data source, costs, survivorship, or lookahead. That tells the agent the result is a purely mathematical check. The readOnlyHint=false/openWorldHint=true annotations are neither repeated nor contradicted; the description adds real context rather than echoing them.

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?

It is reasonably short (four sentences) and front-loads the outputs, but the first sentence is dense and awkwardly constructed, forcing re-reading to parse the three-output mapping. The disclaimer sentences earn their place, but the core sentence could be clearer.

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 non-trivial portfolio-math tool, the description covers purpose, applicability, the three outputs' drivers, and the critical caveat about what data was never inspected. An output schema exists, so return-value explanation is not required. The only gap is the absence of explicit guidance on when to prefer this over a sibling validator.

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, but the description adds the parameter-to-output relationship: sleeve_sharpe plus correlation determine the ceiling, sleeve count determines that book's Sharpe, and target determines the sleeve count needed. That pairing is not obvious from the schema alone, so it earns above baseline.

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 states the three concrete outputs (book Sharpe ceiling, Sharpe at a sleeve count, sleeves required for a target), which is a specific computational purpose rather than a restatement of the name. It also differentiates itself from the sibling single-strategy validators with 'For portfolio construction; it validates no single strategy.' The opening sentence is grammatically elliptical ('Book Sharpe ceiling from adding sleeves...') but the intent is recoverable.

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?

It gives one usage signal — 'For portfolio construction; it validates no single strategy' — which implicitly routes the agent away from the sleeve-less validate_* siblings (validate_deflated_sharpe, validate_haircut_sharpe, etc.). However, it never names an alternative or states a when-not condition, so the selection guidance is implied rather than explicit.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true and destructiveHint=false, so safety signalling is already covered. The description still adds real context beyond that: it explains the two valid input modes (statistics vs. return series) and warns that the resulting probability is not admission to anything and not a forecast. It does not mention auth, cost, or rate limits, but for a local statistical computation that gap is small.

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 whole definition fits in three dense sentences with no filler; the routing alternatives are front-loaded mid-paragraph and the interpretive caveat closes it. It is slightly run-on and could be split, but every clause carries information.

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?

An output schema exists, so return values need no explanation. For a tool with 8 optional parameters and no required inputs, the description covers purpose, the two input modes, sibling alternatives, and interpretation limits. It could go further on which combination of statistics is minimally sufficient, but nothing essential is missing.

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 already 100%, so baseline would be 3, but the description adds the either/or input mode ('the seven statistics or a return series') that the schema only implies via the 'replaces' note on returns. This clarifies mutual exclusivity across the 8 all-optional parameters, which is meaningful routing information beyond the field-level descriptions.

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 states precisely what the tool computes: the probability (0-1) that the selected strategy's Sharpe beats the best luck produces across the variants tried, plus the probabilistic Sharpe and luck benchmark. It also names the sibling tools it is not (validate_overfitting, validate_luck_trials, validate_haircut_sharpe), so the agent can separate it from adjacent validators. It falls short of 5 only because it opens with a concept definition rather than a direct verb+resource statement.

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?

It gives explicit routing: send the seven statistics or a return series; use validate_overfitting when every variant's returns are available; validate_luck_trials when luck is expressed as a trial count; validate_haircut_sharpe for a multiple-testing haircut. The alternative tools and the conditions selecting them are spelled out rather than left to inference.

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

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

Annotations cover the safety profile (destructiveHint=false, openWorldHint=true), so the description's burden is lighter. It adds interpretive behavior ('not admission to anything and is not a forecast') and clarifies which inputs drive which outputs. It does not state that the call is a pure stateless computation or whether anything is persisted, which matters given readOnlyHint=false.

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?

Two sentences, front-loaded with the method and citation, no filler. The second sentence packs two distinct ideas (sibling routing and threshold caveat) and is grammatically dense, but every clause carries information.

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?

An output schema exists, so return values need not be explained; the description still covers method provenance, the routing alternative, and a misuse caveat. It leaves open how this differs operationally from related siblings like validate_luck_trials and validate_overfitting, which is the main remaining gap.

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 all six parameters including worked examples (252 daily, 365 crypto). The description only loosely links inputs to outputs ('by Bonferroni and independent tests', 'with the other tests' Sharpes, Holm and BHY'), which is baseline-level added value.

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?

Names a specific computation (haircut Sharpe for multiple testing, Harvey and Liu 2015) and enumerates exactly what it returns: Bonferroni/independent-test haircuts and Holm/BHY adjustments. It also names the sibling it is not (validate_deflated_sharpe), so an agent can route without opening the schema.

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?

Gives one explicit routing rule: 'For the probability the Sharpe is real, use validate_deflated_sharpe.' That is a real alternative-plus-condition. It does not cover when to prefer this over other siblings such as validate_overfitting or validate_luck_trials, so it stops short of full when/when-not guidance.

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

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

Annotations supply the safety profile (destructiveHint=false, openWorldHint=true), and the description adds genuine extra context: the method is Monte Carlo and luck is defined as the best of N random tries. It also warns that a threshold crossing is neither admission nor forecast, which is useful interpretive guidance. It says nothing about why readOnlyHint is false for what reads as a pure computation, leaving an unexplained annotation/label mismatch.

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, front-loaded with the core computation before the sibling pointer and the caveat. Every sentence carries content, though the opening sentence is syntactically heavy and could be tightened.

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 an output schema present, return values need not be explained, and annotations cover the safety profile. Purpose, sibling routing, and interpretive limits are all present; the main residual gap is the unaddressed readOnlyHint=false for a statistical computation.

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 parameter meanings, defaults (autocorrelation default 0), and bounds are already documented; baseline is 3. The description only implies effective_independent_trials by calling it 'a trial count' and does not add syntax or semantics 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 states a specific computation: how many skill-less strategies a search would need for its best to reach the observed Sharpe by luck, and (given a trial count) the probability of that. It names the sibling it is not (validate_deflated_sharpe), so the agent can separate the two. The phrasing is dense and inverted, which costs it a point but the substance is specific and non-tautological.

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?

It explicitly routes the agent: 'for the probability the Sharpe is real, use validate_deflated_sharpe', and the clause 'with a trial count, the chance it did' signals when to supply effective_independent_trials. The closing caveat about thresholds also frames how to read the result. There is no explicit when-not, but the alternative pointer is clear.

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

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

Annotations only declare readOnly=false, openWorld=true, destructive=false, which says little about a statistical computation. The description compensates with the required input shape and a meaningful interpretive caveat (threshold crossings are neither admission nor forecast), which is real behavioral guidance beyond structured fields. It stops short of runtime traits like cost, determinism, or failure modes when the matrix is malformed.

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?

Front-loads the metric and method, then requirements, then sibling routing, then the interpretation caveat. Three dense sentences with no filler, each carrying distinct information.

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?

An output schema exists, so return values need not be explained, and the description covers inputs, the alternative tool, and result interpretation for a non-trivial statistical procedure. It could say more about assumptions (e.g. minimum period/variant counts) or determinism, but nothing essential to correct invocation is missing.

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 matrix, seed, n_splits, and max_combinations. The description's 'periods by variants' restates the matrix schema description rather than adding syntax or constraints. Baseline 3 applies when the schema does the heavy lifting.

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?

Names a specific outcome (probability of backtest overfitting, 0-1) and the method (CSCV), then defines the metric operationally as how often the in-sample best variant falls below the out-of-sample median. It explicitly distinguishes itself from validate_deflated_sharpe, so an agent can route without opening either schema.

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?

States the input condition that selects this tool (every variant's returns required) and names the alternative for the other case (summary statistics only -> validate_deflated_sharpe). This is an explicit when/alternatives pairing, not implied usage.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description usefully adds that the verdict concerns the submitted series only and that the service never saw the data source, costs, survivorship, or lookahead. This is exactly the kind of limitation an agent needs. It stops short of stating permission requirements or whether calling it has side effects (notably, readOnlyHint=false is left unexplained).

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?

Front-loaded with purpose and output, and each sentence is short. The final two sentences overlap somewhat, both reassuring about what the verdict does not cover, which is mild redundancy rather than waste.

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?

An output schema exists, so return values need not be explained, and the description correctly delimits what the verdict does and does not assert. Given the single nested object parameter, this is nearly complete; only the missing sibling routing keeps it from a 5.

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?

One parameter with 100% schema description coverage, so the schema already carries the semantics. The description's mention of canli.paper-evidence.v0 simply restates the schema's own description and adds no new syntax or format detail.

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 names a specific verb and resource (validates a paper/simulated performance record against canli.paper-evidence.v0) and states the output shape (JSON pointer per failure). It does not, however, differentiate itself from the many sibling validate_* tools, leaving the agent to infer which validator applies.

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?

It clarifies scope by negation ('checks structure and required disclosures, not whether the returns are good'), which implies when the tool is appropriate. But it never names an alternative or states a positive trigger condition versus siblings like validate_track_record or validate_backtest.

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

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

Annotations already carry the safety profile (destructiveHint=false, openWorldHint=true), and the description adds a genuine interpretive caveat beyond them: a deflated Sharpe or overfitting probability above/below a threshold "is not admission to anything and is not a forecast." That tells the agent the output is diagnostic, not a decision — useful context the annotations do not convey.

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?

Two sentences, front-loaded with what the tool computes and then the input rule. Dense but each clause earns its place; minor run-on structure in the second sentence keeps it from a 5.

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 an output schema present, return values need not be explained; all seven parameters are fully described in the schema, and the description supplies the key input expectation (include every variant tried). For a stateless computation tool this is essentially complete, missing only explicit sibling routing.

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 all seven parameters including defaults and bounds, and the baseline is 3. The description only reinforces the matrix requirement ("every variant a search tried"), which the schema already states, so it adds little beyond the structured 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?

Names a specific resource (data-snooping tests) plus the three concrete tests it runs (SPA p-value, White's Reality Check, Romano-Wolf StepM), so the agent knows exactly what computation happens. It only implicitly separates itself from siblings like validate_deflated_sharpe and validate_overfitting via the closing caveat rather than stating routing outright.

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?

"Send all variants tried, not only the winners" is an explicit, actionable usage directive that tells the agent what input to gather, which most siblings don't provide. It stops short of naming when to pick this over validate_deflated_sharpe or validate_overfitting, so it is clear context rather than full when/when-not guidance.

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

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are somewhat at odds with an obvious pure-calculation tool, and the description neither confirms nor contradicts them. It does add interpretive context ('not admission to anything and is not a forecast') and discloses that output includes observations/years, but says nothing about precision, numerical caveats, or failure modes.

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, front-loaded with the core computation and then the sibling routing. The final disclaimer sentence is useful but slightly tangential and the first sentence is dense with nested clauses, costing a little clarity.

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 an output schema present and full schema coverage, the description does not need to explain return values, and it covers purpose, scope, and routing. It is complete enough to invoke correctly, though it never explains what the periodic/year conversion or confidence inputs imply about results.

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 defines every parameter, including defaults (benchmark 0, confidence 0.95). The description names 'observations', 'confidence level', and benchmark only in passing and adds no format or edge-case semantics beyond the schema, so baseline 3 applies.

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?

States a specific computation (minimum track record length, in observations and years) on a named resource (an observed Sharpe vs a benchmark) and explicitly names the sibling it is not: validate_backtest_length. An agent can distinguish it from the several validate_* siblings without opening the schema.

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?

Gives an explicit when ('For live or paper records') and an explicit alternative with its selecting condition ('to size a backtest for its trials, use validate_backtest_length'). It also warns what the tool is not for, which is exactly the routing guidance an agent needs among near-identical validate_* siblings.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, and the description goes beyond them by disclosing that verification happens offline, that the trust anchor is a specific bundled key, and that the key is published at a well-known URL. It stops short of describing failure modes or what makes verification fail.

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?

Two dense, front-loaded sentences that lead with the action and the checks performed; the reproducibility and key-publication details are useful but slightly burden the second sentence. Nothing is redundant.

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 an output schema present, return values need no explanation, and the annotations carry the safety profile. The description covers the cryptographic scope and both input paths, leaving only edge-case behavior (e.g., malformed receipts, network failure when fetching by id) unspecified.

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 description adds genuine semantics: passing an id triggers an internal fetch while passing a receipt object verifies without fetching. That behavioral distinction between the two optional parameters is not evident from the schema alone.

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?

States a specific verb (verify) and resource (receipt) and enumerates exactly what is checked: the Ed25519 signature, the output hash, and the id. The phrase 'Send an id to fetch it first' implicitly differentiates it from the sibling get_receipt, which only retrieves.

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 clearly spells out the two mutually exclusive input modes ('Send an id to fetch it first, or the receipt itself'), which is real usage guidance for an agent choosing how to call it. It does not, however, state when verification is unnecessary or how it relates to validate_* siblings.

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