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

Annotations already mark it read-only and non-destructive; the description adds auth requirements ('No key required'), ordering ('newest first'), output fields (accession, form, filed date, unit, SHA-256), and provenance (SEC-reported, 'companies in the release only'). No contradiction with 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 a single dense paragraph and front-loads the resource and lookup mode before behavioral detail. It is mostly efficient, though the 'not returns' caveat appears twice (in the disclaimers and the validation sentence), making it slightly 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?

For a read-only tool with no output schema and four unannotated parameters, the description covers lookup, output shape, ordering, auth, and exclusions. It falls short only on `limit` behavior and the mutual-exclusion/priority of cik vs ticker, so it is very close but not fully complete.

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?

With 0% schema description coverage, the description must define the parameters and does so for cik, ticker (including resolution endpoint) and concept (with/without behavior). It omits the semantics of `limit`, and doesn't address what happens when both cik and ticker are supplied, so it is not fully complete.

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 resource ('SEC-reported financial history for one company from the canlicapital.com company reference'), the lookup methods (cik or ticker), and the two modes (list histories vs observations). It explicitly distinguishes itself from the validation-tool siblings by stating it is not returns, market prices, or ALPHAC performance.

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 concrete usage rules: identify by cik or ticker, only companies in the release, no key required, and without a concept vs with one. It also tells the agent when not to use it—for return series—and points to the validation API instead.

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 annotations (readOnlyHint false, idempotentHint false), it clarifies that the key is held in memory for the session and lists detailed quotas. It does not contradict annotations, but omits return value and error behavior, which are minor given 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 information-dense but efficient, front-loading purpose and usage, then quotas. Each sentence serves a purpose, though the quota list is long; it could be condensed without losing essential 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?

It covers purpose, usage, and quotas well, but omits the meaning of the 'label' parameter and does not describe what the tool returns (e.g., the key itself). Since there is no output schema, this gap is notable. However, the tool is simple and most operational context is present.

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 schema has one optional parameter 'label' with maxLength 64, but the description never mentions it. Schema description coverage is 0%, so the description provides no help for this parameter, leaving the agent to guess its meaning.

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 explicitly states the action (issue a validation key), the resource (free canlicapital.com key), and the HTTP endpoint. It differentiates from sibling read tools by noting they never need a key, making its role clear.

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 precise conditions: 'Only needed before a validation when neither CANLI_KEY nor local mode is set' and explicitly excludes read tools. It also provides quota limits, offering concrete guidance on when to use and potential constraints.

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?

Even with readOnlyHint/openWorldHint/destructiveHint annotations, the description adds distinct behavioral facts: the receipt is immutable and cacheable, reproducible from the named open-source core, and unsigned. These traits inform caching and trust expectations and go well beyond 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 three sentences, with the core action and endpoint in the first sentence and important behavioral caveats after. No redundant or promotional language appears.

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 simple single-parameter retrieval, the description is largely complete: purpose, id semantics, and behavioral traits are all present. No output schema exists, so the description does not detail the returned representation, but the minimal contract makes that a minor 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?

With schema description coverage at 0%, the description compensates by explaining that id is a content-hash id and that receipts are content-hashed and reproducible from the open-source core. This gives semantic meaning beyond the schema's type/pattern and is sufficient for the single required parameter.

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?

Clearly names the action ('Fetch'), resource ('stored verdict'), and identifies the id as a content-hash id. It also gives the REST route, which differentiates it from validation and key tools. The title and description agree, and 'stored verdict' clarifies what a receipt 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?

The description implies the trigger: when a caller has a content-hash id and wants the stored verdict/receipt. However, it does not explicitly compare with sibling tools such as get_key or state when not to use this tool, so usage guidance is only implicit.

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, openWorldHint=true, and destructiveHint=false. The description adds meaningful context beyond these annotations: no authentication is needed, and the status is computed purely from the series as submitted, with no hidden data source, lookahead, or survivorship considerations. This clarifies what the 'status' actually represents and helps the agent set expectations.

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 brief and front-loaded with the primary purpose and endpoint. The second sentence provides valuable context about the verdict's scope, but it could be seen as slightly tangential for tool selection. Still, every sentence earns its place, and there is no redundancy. It is appropriately sized for a zero-parameter 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?

For a zero-parameter read-only status endpoint with annotations already covering safety and openness, the description gives sufficient information to invoke it correctly: what it returns (constants), the auth requirement, and the semantic foundation of the verdict. It does not describe the response format, but with no output schema and a simple status use case, this is a minor 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?

The tool has zero parameters and schema coverage is 100%, so the schema already fully specifies the input. The description reinforces that no key is required, which is not exactly a parameter but useful auth context. With no parameters to document, the baseline is 4, and the description does not need to do more.

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 resource ('GET /api/v1/validate/status') and defines the payload as 'service, store and quota constants'. The added 'no key required' distinguishes it from key-requiring peers like get_key, and the phrase 'validation API' places it in context. It is clear and specific enough for an agent to know what this tool does and that it is a status endpoint.

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 useful context: it is a public status/constants endpoint requiring no key, and it clarifies the semantic scope of the returned verdict. However, it does not explicitly say when to choose this over siblings or when not to use it. The 'no key required' hint and endpoint path imply its place, but no direct alternative routing is provided.

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 provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds meaningful context about what the service did not see (data source, costs, survivorship, lookahead) and states that the verdict concerns the series exactly as submitted. This clarifies the tool's scope and limitations beyond the annotations, though it does not disclose potential side effects or what the tool does with the inputs.

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 two sentences with no filler. The first sentence conveys the core function, and the second adds a key limitation. It is reasonably front-loaded, though the use of 'Book' and the dense phrasing reduce immediate 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 no output schema, the description should explain what the tool returns (a verdict) and how the parameters affect it. It only says 'This verdict is about the series exactly as submitted', which is vague. There is no explanation of edge cases, how the ceiling is computed, or what inputs are mandatory. For a tool with 4 parameters and no schema documentation, this is incomplete.

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 0%, so the description must compensate for parameter meanings. It refers to 'per-sleeve quality' and 'average pairwise correlation' and 'sleeves a target needs', which map roughly to sleeve_sharpe, average_pairwise_correlation, sleeves, and target. However, it does not explain the exact meaning of 'target', whether parameters are optional, or any constraints or formulas relating them. This is insufficient for an agent to correctly fill all parameters.

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 operation ('Book Sharpe ceiling') and the inputs it derives from (per-sleeve quality, average pairwise correlation, sleeves), which clearly relates to the title 'Validate breadth ceiling'. It is distinguishable from sibling validation tools by its focus on breadth/ceiling calculations, though the verb 'Book' is ambiguous and could be clearer.

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?

No guidance is given on when to use this tool versus the sibling validators (e.g., validate_overfitting, validate_deflated_sharpe). The description only notes the service's limitations (never saw data source, costs, survivorship, lookahead) but does not specify when this tool is appropriate or when to select an alternative.

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?

The annotations only provide sparse hints (readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the description carries the burden of behavior. It adds meaningful context: the tool accepts two mutually exclusive input forms, and the result should not be treated as admission or a forecast. This is valuable beyond the schema and annotations, though it does not describe error behavior or side effects.

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 two sentences with no filler. The first sentence states what the tool does and the key input-mode constraint; the second adds an important interpretive caveat. Both sentences earn their place and the structure is easy to scan.

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?

The tool has 8 parameters, no required parameters, no output schema, and no parameter-level documentation. The description does not specify return values, how to choose between the two input modes, or which parameters belong to each mode. For correct invocation, an agent needs significantly more contextual information than this provides.

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?

With 0% schema description coverage and 8 undocumented parameters, the description only hints at broad groups: 'seven contract inputs' versus a return series plus trials and dispersion. It does not map these groups to the actual parameter names, leaving the agent unable to construct a valid parameter set from the description 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?

The description clearly states that the tool produces a probabilistic and deflated Sharpe from one of two input groups, and it uses 'never both' to define scope. It stops short of a 5 because 'seven contract inputs' is not enumerated and it does not explicitly differentiate itself from sibling validation tools.

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 the operational constraint 'never both' between two input modes, which is useful, but it gives no guidance on when to choose this tool over the sibling tools such as validate_overfitting or validate_track_record. An agent has to infer applicability from the title and name rather than from explicit usage direction.

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 are present (readOnlyHint=false, destructiveHint=false) but carry little information since false for both could mean a neutral operation. The description adds the caveat that the probability is not admission or forecast, which is a useful behavioral disclosure about the meaning of the output. However, it does not mention whether the operation mutates anything, performance implications, or prerequisites beyond the matrix. The caveat adds some value but does not fully compensate for the sparse annotation context.

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 two sentences, both front-loaded with the core purpose first and the caveat second. It is concise with no fluff, and every sentence serves a purpose. The brevity is appropriate for a tool with a single required parameter, though the lack of parameter details could have been accommodated without excessive length.

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 has four parameters (only one required), no output schema, and no parameter descriptions, the description is notably incomplete. It does not explain the CSCV method, the expected shape of the matrix (e.g., rows as trials, columns as samples), the meaning of the output (just 'probability' without units or range), or how n_splits and max_combinations affect the computation. The caveat about interpretation is helpful but insufficient to make the tool callable correctly without additional 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 description coverage is 0%, so the description must explain all parameters. It only indirectly references the 'matrix' parameter via 'returns of every variant tried,' but does not explain the structure or constraints of the matrix. It completely omits any explanation of 'seed', 'n_splits', or 'max_combinations', leaving the agent without guidance on how to set these parameters. This is a significant gap given the lack of schema 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 clearly states it computes 'Probability of backtest overfitting by CSCV over the returns of every variant tried.' It names the specific method (CSCV) and the input (returns of every variant), making it distinguishable from siblings like validate_deflated_sharpe or validate_breadth by the concept of overfitting. However, it does not explicitly contrast itself with any sibling tool, so it misses the full differentiation an explicit alternative would provide.

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 no guidance on when to use this tool versus the sibling validation tools. It only includes a caveat that the result is not admission or a forecast, which is interpretive rather than usage guidance. There is no mention of conditions that would select this tool over validate_deflated_sharpe or validate_track_record.

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 reveals meaningful behavioral boundaries: the service never sees the data source, costs, survivorship, or lookahead in how the series was built, and the verdict is limited to the submitted series. This helps an agent understand what the tool does and does not inspect.

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 two sentences with no filler. The core conformance-checking purpose is front-loaded, and the second sentence adds precise scope limitations that are directly useful for selecting and invoking 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?

There is no output schema, yet the description does not explain what the validation result looks like, such as a boolean, a detailed report, or a structured verdict. Combined with the vague parameter documentation, the description is not sufficiently complete for an agent to confidently construct input and interpret output.

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 0%, so the description must compensate. It identifies the single parameter, 'record', as a performance record and mentions the series, but it does not specify the expected object shape, required fields, or how the series should be represented. An agent still lacks enough detail to construct a valid record.

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 states that the tool evaluates conformance of a performance record against the canli.paper-evidence.v0 standard. It distinguishes itself from sibling validators by naming a specific standard and emphasizing that the verdict concerns the series exactly as submitted.

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 intended use is implied: call this tool to check whether a performance record conforms to the paper-evidence standard. However, it does not explicitly state when to prefer this tool over sibling validators like validate_track_record or validate_overfitting, nor does it provide exclusion criteria.

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?

With sparse annotations (readOnlyHint false, destructiveHint false, openWorldHint true), the description carries the burden of behavioral disclosure but only partially. It adds useful conditional behavior: when observations is sent, probabilistic Sharpe is also returned, and it cautions against misusing results as admission/forecast. It does not disclose any side effects, persistence, or why readOnlyHint is false, leaving some ambiguity for a tool that appears computational.

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 compact at two sentences, with the core purpose and defaults front-loaded in the first sentence. The second sentence adds a meaningful interpretive warning rather than filler. It is somewhat dense and technical, but it earns its space given the complexity.

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?

The tool has 7 parameters, no output schema, and siblings that cover related statistical validations. The description explains the core calculation and conditional output in prose, but does not specify return format/units, clarify all required parameters, or map to sibling tools. Given the complexity and lack of schema descriptions, this is incomplete for reliable agent invocation.

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 0%, so the description must clarify parameters, but it only addresses a few: benchmark Sharpe (default 0), confidence (default 0.95), and observations (triggers probabilistic Sharpe). It does not explain skew, non_excess_kurtosis, periods_per_year, or observed_sharpe_annualized beyond echoing schema names, leaving critical inputs under-specified for a 7-parameter tool.

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 uses a specific verb-object structure: it calculates the minimum track record length for an observed Sharpe to clear a benchmark at a confidence level, and optionally computes probabilistic Sharpe when observations is provided. This clearly states what the tool does and distinguishes it conceptually from deflated Sharpe and overfitting probability, though it does not name sibling tools directly.

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 implies when to use the tool: when you need a minimum track record length or a probabilistic Sharpe for a given observation count. It also warns that deflated Sharpe/overfitting outputs are not admission or forecasts, giving some interpretive guardrails. However, it does not explicitly state when to choose this tool over validate_deflated_sharpe or validate_overfitting, nor does it mention exclusions.

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