FiledProof

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

Annotations already cover read-only, idempotent, open-world and non-destructive traits, but the description adds meaningful context: history persistence/reuse, deterministic fingerprints, exact SEC evidence, and the important caveat that "structural change is not a materiality judgment." That caveat and the persistence semantics go beyond the structured fields.

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 front-loaded sentences that move from action, to output, to caveat. Dense but each clause carries information; no 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?

With no output schema, the description carries the return-value burden and does so by naming fingerprints and transition edges. Combined with the materiality caveat and bounded-inspection framing, it is sufficiently complete for calling the tool correctly, though it does not elaborate on the persistence lifecycle.

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 ten parameters are fully documented in the schema itself. The description adds only the general issuer/topic framing and does not enrich individual parameter meaning, making the baseline 3 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?

The description gives a specific verb+resource: "build or reuse a persisted issuer/topic disclosure history from bounded SEC filings," and clarifies the output as per-filing fingerprints plus same-form transition edges. It implicitly separates itself from comparison siblings ("without reconstructing prior comparisons itself") but never names a specific sibling, so it stops short of a 5.

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?

Usage is implied by the stated goal (an upstream agent inspecting how disclosure evolved) and the hint that it avoids rebuilding comparisons. However, there is no explicit when-to-use vs when-not guidance or named alternative among siblings like compare_filings, check_disclosure_changes, or build_disclosure_matrix.

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 read-only, idempotent, non-destructive, open-world behavior, and the description adds real context: it is a read-only evidence substrate with aggregate reuse state, deliberately not a ranking or materiality judgment. It does not cover auth requirements, cost/latency, or how lineage reuse is triggered.

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 action, and the second sentence efficiently explains the return payload and why it exists. The middle sentence is long and clause-heavy, but every clause earns its place.

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 13-parameter tool with no output schema, the description usefully characterizes the return payload (current evidence, transition evidence, reuse state) and the tool's epistemic limits. The gap is that several tuning parameters affecting behavior remain opaque, but an agent has enough to decide when and how to call it.

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 69% schema description coverage, several parameters (history, comparisonLimit, maxArchiveFiles, fingerprintLimit) carry no description anywhere. The description only corroborates the identifiers bound (two to six companies) and the topic concept, adding essentially no syntax or meaning beyond the schema; baseline 3 is the right anchor here.

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: aligning a disclosure topic across two to six public companies from source-backed historical disclosure lineage, and enumerates the three outputs (current filing evidence, latest same-form transition evidence, aggregate reuse state). It also bounds the tool negatively ('an evidence substrate, not a ranking or materiality judgment'). It stops short of naming the sibling it supersedes (compare_filings / build_disclosure_lineage), so it is clear but not fully differentiated.

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 clear context for use: cross-company alignment of one topic where the caller would otherwise retrieve, parse, align, and re-compare each filing history separately. That implies the alternative (manual or per-company sibling calls) but no sibling is named and no when-not guidance is given.

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 readOnly=true, idempotent=true, openWorld=true, destructive=false, so safety is covered. The description adds genuine behavioral value beyond that: it specifies what the output preserves (URLs, locators, scope, coverage) and that non-inference rules are enforced, which signals research-integrity behavior.

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?

A single dense sentence with the verb and scope front-loaded and zero filler. It is efficient, though the trailing list of preserved artifacts makes it slightly long for one clause.

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 an 8-parameter build tool with no output schema, the description adequately characterizes the returned evidence pack, which is the most important thing. It is missing usage/routing guidance and any note on the undocumented pagination-like parameters, leaving a real 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 63%, in the middle band; the description adds no parameter-level meaning at all. The undocumented parameters (limit, filings, history) are self-explanatory by name, but the description neither compensates nor explains defaults or intent for them.

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 (package) and resource (SEC evidence) with concrete scope: source URLs, locators, search scope, coverage, non-inference rules. An agent understands this produces an evidence deliverable for a downstream agent. It does not, however, distinguish itself from siblings like search_evidence or verify_claim.

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 phrase 'for an upstream AI agent' hints at context, but there is no explicit when-to-use, no when-not-to-use, and no alternative named among the ten sibling tools (search_evidence, verify_claim, etc.). The agent must infer routing on its own.

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, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The phrase 'without inventing semantic change or materiality' adds a genuine behavioral constraint (the tool orders evidence but does not infer causation). However, the description says nothing about the bounded-filings limit behavior or output ordering guarantees, and no output schema exists to carry the return shape.

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?

One dense sentence with no filler, and the key constraint ('chronologically') is front-loaded. It is efficient, though a second short sentence clarifying the boundary against sibling timeline-like tools would have paid for itself.

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 an 8-parameter read-only tool with no output schema, the description covers the core concept but omits return shape, how 'bounded set' controls output size, and how to pick it over the three other build_* siblings. Adequate but with clear gaps.

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 63%, above the low-coverage threshold, so the baseline of 3 applies. The description adds 'bounded set of SEC filings' which loosely relates to the filings parameter (default 3, max 6) but does not explain it; parameters like limit, history, and item are left entirely to 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?

States a clear verb ('Organize') and resource ('filing evidence') with a scope constraint ('chronologically across a bounded set of SEC filings'). It distinguishes from sibling build_disclosure_lineage and build_disclosure_matrix only implicitly by the word 'chronologically' — an agent might need to open those schemas to know which to choose.

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 when-to-use, when-not-to-use, or named alternatives. The description says what it does but gives no condition that would select it over build_disclosure_lineage, build_disclosure_matrix, or build_evidence_pack, all of which are similarly named sibling builders.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds real behavioral context beyond them: it processes filings chronologically, compares each against the prior filing of the same form, returns only topic-relevant added/removed evidence, and describes the checkpoint persistence pattern the caller must maintain.

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 tight sentences with zero filler; the scope constraint and the checkpoint mechanic are front-loaded, and each sentence adds distinct information (scope, processing model, return + workflow).

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 9-parameter, output-schema-less read tool, the description covers scope, processing semantics, return content, and the checkpoint lifecycle an agent must persist. It leaves unspecified the exact shape of the returned records and the non-updated params, but nothing essential to calling it correctly 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 78% with 9 parameters, so the schema already documents most fields (forms default, limit, maxNewFilings, topic, identifier). The description only sharpens the meaning of sinceAccession via the checkpoint workflow; it adds nothing for history, comparisonLimit, or item, so a 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 ('check') and resource ('one issuer for new monitored filings'), plus the incremental scope ('since an optional checkpoint accession'). The incremental-checkpoint framing distinguishes it conceptually from a full-scan sibling, but the description never names scan_disclosure_changes or compare_filings, so the differentiation is left to inference.

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 clear operational context for the first call ('Omit for the first snapshot') versus subsequent calls ('Save checkpoint.accession and supply it on the next call'), which is genuine when-to-use guidance for a stateful tool. However, it offers no exclusions or comparison against the closely-named scan_disclosure_changes alternative, leaving the boundary with siblings ambiguous.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful context about what is returned (source-backed added/removed blocks) and a semantic scope boundary, but says nothing about pagination behavior, the limit cap, or provenance/confidence of the 'source-backed' output.

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 tightly written sentences with the core action front-loaded and no filler. The second sentence earns its place as a scope caveat, though its phrasing ('structural change is not semantic interpretation') is slightly abstract.

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 five-parameter tool with no output schema, the description should carry more: it omits how the result set is bounded (limit default 100, max 500), how 'item' narrows the comparison, and what an added/removed block looks like. The stated return content partially compensates.

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 80%, so left/right/identifier/item are largely self-documenting and the baseline is 3. The description reinforces the same-issuer constraint tying left and right together, but adds no detail on the 'item' filter or the limit parameter's effect.

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 (compare two filings from the same issuer) and names the output (added and removed disclosure blocks). It does not differentiate itself from close siblings such as check_disclosure_changes or scan_disclosure_changes, so an agent must still infer which comparison tool to pick.

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 precondition 'from the same issuer' and the caveat 'structural change is not semantic interpretation' imply when this tool is appropriate (pairwise structural diff, not semantic analysis). However, no alternative tool is named and there is no explicit when-not guidance against the several sibling change-detection tools.

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 readOnly, idempotent, non-destructive, and openWorld, so the safety profile is fully covered. The description adds some useful behavioral context via 'canonical source metadata' and 'explicit coverage limits,' hinting at result quality and boundedness, but does not elaborate on what those limits actually are.

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?

A single front-loaded sentence with no filler; the core action and scope lead. It is efficient, though the compressed phrasing leaves meaning ('canonical source metadata,' 'coverage limits') underspecified rather than fully earning its place.

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 and 75% of parameters undocumented, the description carries a heavy burden it does not meet. It gestures at return content and coverage limits but never enumerates them, and gives no guidance on the forms/limit/history parameters an agent must set to call the tool 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 only 25%: identifier is documented ('Ticker, CIK, or exact SEC company name') but forms, limit, and history are not explained anywhere. The description does not compensate by clarifying what forms accepts, what limit controls, or when history changes behavior, so an agent must infer from bare types and defaults.

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 (List) and resource (SEC filings), plus scope qualifiers (recent vs bounded historical) and the promise of canonical source metadata. It is clear what the tool does, but it does not differentiate itself from siblings like search_evidence or compare_filings, which also touch filings.

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 explicit when-to-use guidance and no named alternatives. The phrase 'recent or bounded historical' hints at the history flag's purpose but never says when to enable it or when a sibling tool is the better choice.

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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds the authoritative data source ('official SEC company dataset') and timing context, but says nothing about miss behavior (unresolvable identifiers) or ambiguous matches, which is the main behavioral risk for a resolution tool.

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 that each earn their place: the first defines the operation and its source of truth, the second gives the trigger condition. Front-loaded and free of padding.

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 one-parameter read tool with rich annotations, the description is nearly sufficient, but with no output schema it leaves the return value undefined — an agent cannot tell whether resolution yields a CIK, canonical name, match list, or failure signal. That gap matters for a tool whose output feeds downstream research.

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 string parameter is fully documented, so the baseline of 3 applies. The description's mention of 'ticker, CIK, or exact company name' merely restates the schema's own parameter description ('Ticker, CIK, or exact SEC company name') without adding format, casing, or matching-precedence 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?

States a specific verb ('Resolve') and enumerates the accepted resource forms (ticker, CIK, exact company name) against the 'official SEC company dataset', which is concrete and unambiguous. No sibling in the filedproof set performs issuer identity resolution, so the tool is implicitly distinct, but the description never names or excludes an alternative, keeping it short of a 5.

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?

'Use this before research when issuer identity is uncertain' gives an explicit trigger condition and sequencing guidance relative to downstream tools. It stops short of stating when NOT to use it (e.g., when the CIK is already known) or naming an alternative lookup path.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: per-company fault isolation ('one failure does not fail the batch') and the checkpoint-return contract that drives the next run.

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 short sentences, zero filler, front-loaded with the core action, then isolation guarantee, then return contract. Each sentence earns its place.

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 9-parameter tool with a nested checkpoints object and no output schema, the description covers the batch semantics and return contract but leaves most tuning parameters and the shape of per-issuer results (successful vs failed companies) undiscussed. Adequate but with real gaps.

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 67%, so much is already documented. The description adds the 10-issuer ceiling and the notion of checkpoint round-tripping, but says nothing about item, forms, limit, history, maxNewFilings, or comparisonLimit, leaving the higher-cost tuning knobs unexplained.

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 ('Run the same checkpointed disclosure-change monitor') plus a bounded scope ('across up to 10 issuers'). It implies a batch counterpart to the singular check_disclosure_changes sibling but never names it, so differentiation is left to inference.

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 'up to 10 issuers' framing and 'return updated checkpoints for the next agent run' imply the multi-issuer, repeated-monitoring use case. However, it never states when to prefer this over check_disclosure_changes or any other sibling, nor any exclusions.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds real value by disclosing the return contract ("evidence.v1 records with provenance") and the epistemic caveat that lexical relevance is not truth, which shapes how an agent should treat results.

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 tight sentences with zero filler; the retrieval scope is front-loaded and the return/caveat clause follows. Every phrase earns its place.

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 an open-world, 8-parameter retrieval tool with no output schema, the description supplies the return type and a key interpretive caveat, which is genuinely useful. It still omits the default form set (10-K/10-Q), how the "bounded set" is bounded, and result-shape detail, leaving gaps for a tool of this complexity.

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?

At 63% schema description coverage, three parameters (limit, filings, history) carry no description in either place, and the description adds nothing about item, section, forms defaults, or result limits. Baselines do not apply because coverage is not high, and the description fails to compensate for the gap.

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 ("Find") and resource ("primary-source evidence") with scope ("across a bounded set of SEC filings"), and the caveat "relevance is not a truth verdict" implicitly distinguishes it from verify_claim. No sibling is named explicitly, so it falls short of full differentiation but is clearly more than a bare restatement.

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 phrase "relevance is not a truth verdict" hints that verification belongs to another tool, and "bounded set of SEC filings" implies the retrieval scope. However, there is no explicit when-to-use/when-not or named alternative (e.g., scan_disclosure_changes, compare_filings), so usage is only implied.

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 it as a safe, idempotent, open-world read, so the safety profile is covered. The description adds genuinely useful context beyond that: it conservatively returns evidence plus deterministic stance signals, and it warns that a filing establishes what the company reported, not real-world truth — an important epistemic caveat for interpretation.

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 tight sentences, front-loaded with the verdict scope, followed by the return shape and the interpretive caveat. Every sentence earns its place with no redundancy.

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 usefully previews the return (evidence plus stance signals) and the verdict range. The main gap is parameter-level guidance for the optional filters and numeric caps, which an 8-param tool would benefit from.

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 only 63%, and limit, filings, and history carry no descriptions at all in the schema. The description mentions no parameters whatsoever, so it does not compensate for the undocumented third — defaults, the filings/limit caps, and the history flag remain unexplained.

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 (assess/verify) and resource (a claim against SEC filing evidence) and enumerates the verdict spectrum, which makes it clearly distinct from retrieval siblings like search_evidence. It never names a sibling explicitly, so it falls just short of the 5 benchmark that requires explicit differentiation.

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?

Usage is implied: you supply a claim and an issuer to get a verdict. But there is no explicit when-to-use guidance, no statement of when to prefer search_evidence or build_evidence_pack, and no prerequisites (e.g., whether the issuer must first be resolved via resolve_issuer).

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