FiledProof

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

With readOnly/idempotent/openWorld annotations already covering the safety profile, the description adds real value: persistence and reuse semantics ('Build or reuse a persisted ... history'), determinism of the fingerprints, bounded scope, and the important caveat that structural change is not a materiality judgment. It still doesn't disclose reuse conditions (when the cache is considered sufficient) at a level an agent could act on independently.

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 action and resource, and each sentence carries a distinct payload (action, return contract, caveat). Density is high but nothing is redundant with the title; the middle sentence is slightly overloaded.

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 the description needn't explain return values, and annotations plus 100% schema coverage handle safety and parameters. The description still contributes the persistence/determinism framing and the materiality caveat, making the definition essentially complete for a 10-parameter read tool.

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 explains identifier, topic, forms, filings, and the various limits; baseline is 3. The description adds only the notion of bounded history and same-form edges, no syntax or selection guidance 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?

States a specific verb+resource: 'Build or reuse a persisted issuer/topic disclosure history from bounded SEC filings', and the outputs (per-filing fingerprints, same-form transition edges) are named concretely. It does not name any sibling such as build_disclosure_matrix or compare_filings to disambiguate, 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 rather than stated: 'so an upstream agent can inspect how disclosure evolved without reconstructing prior comparisons itself' gestures at why you'd pick this over manual comparison, but there is no explicit when-to-use or when-not rule and no sibling is named as an alternative. Adequate inference, 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is clear. The description adds important behavioral context beyond annotations: it specifies that the matrix is an evidence substrate and explicitly disclaims any ranking or materiality judgment, which is a genuine behavioral scope statement. It does not disclose rate limits or failure modes, but with rich annotations a 4 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?

The description is three sentences, front-loaded with the core action and resource, then the return shape, then a scope disclaimer. It is efficient and non-redundant, though the middle sentence is dense and could be slightly 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?

The tool has a rich output schema, so return values need not be explained in the description; the description still summarises the three evidence categories returned. With 13 parameters and a complex cross-company alignment task, the description covers purpose, output shape and scope limits, but does not clarify edge cases such as behavior when a company lacks the topic or how forms interact across incomparable issuers.

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 13 parameters including identifiers, topic, forms, limit and comparison limits. The description does not add parameter-level syntax, defaults or format guidance beyond what the schema provides, so a baseline 3 is correct 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?

The description states a specific verb (align) and resource (a disclosure topic across two to six public companies), and it explicitly names the output artifact (a cross-company disclosure matrix backed by source-supported historical lineage). This distinguishes it from siblings like build_disclosure_lineage (single-company lineage) and compare_filings (pairwise filing comparison).

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 explains the tool is for upstream agents that would otherwise retrieve, parse, align and re-compare every filing history, which implies the intended workflow, but it does not explicitly say when to prefer this over sibling tools like build_disclosure_lineage, compare_filings or build_evidence_pack, nor does it state exclusions or prerequisites.

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 real context: the output preserves source URLs, locators, search scope, coverage, and 'explicit non-inference rules,' the last hinting at a no-hallucination guarantee. That is useful but thin for an 8-parameter pipeline tool with no stated limits or auth needs.

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?

Single dense sentence, front-loaded with the core action and purpose. It wastes little, though the trailing list of preserved artifacts ('source URLs, locators, search scope, coverage...') is somewhat enumerative rather than additive.

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, return-format details are not needed. However, for a complex multi-parameter tool the description omits when this step belongs in the evidence workflow and how it differs from search_evidence, leaving a meaningful 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 8 parameters including identifier, q, forms, and the limit/filings caps. The description adds no parameter-level meaning beyond that, so the baseline 3 is correct.

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 ('the strongest relevant SEC evidence'), and specifies the audience ('an upstream AI agent'). It is clear what the tool produces, though it never names or contrasts with siblings like search_evidence or verify_claim, which operate in the same evidence-gathering space.

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 no when-to-use conditions, no prerequisites, and no alternatives. It does not tell the agent when to reach for build_evidence_pack versus search_evidence, verify_claim, or the other build_* siblings, leaving selection entirely 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 already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral constraint — it will not 'invent semantic change or materiality' — which is useful, but it says nothing about cost, latency, or how the bounded filing/limit caps affect 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?

A single front-loaded sentence with no filler, and the key constraint is placed at the end where it lands. It is dense and slightly abstract but nothing is wasted.

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 the read-only annotations cover the risk profile. What remains thin is operational context: how the bounded forms/filings/limit caps shape output and when this tool beats its siblings, leaving it only minimally viable for an 8-parameter tool.

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% across all 8 parameters, so the schema already carries parameter meaning (q, item, forms, section, history, etc.). The description adds no syntax, defaults, or interaction details beyond what the schema documents, making baseline 3 the correct score.

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 ('organize ... chronologically') and resource ('filing evidence ... across a bounded set of SEC filings'), which is enough to distinguish it from search_evidence or compare_filings. It does not name or contrast the closest siblings (build_disclosure_lineage, build_disclosure_matrix, build_evidence_pack), 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?

There is no explicit when-to-use guidance and no exclusion or alternative named. 'Across a bounded set of SEC filings' hints at scope but leaves the agent to infer when a chronological timeline is preferable to the lineage, matrix, or evidence-pack 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?

The description adds substantial behavioral context beyond the annotations: it discloses the $15.00 paid operation, retry-safe checkpoint state, deterministic attention triage, non-materiality caveat, and preflight rejection before charge. This is exactly the kind of operational transparency an agent needs, especially given the readOnly and idempotent 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 dense but efficiently structured: cost and scope are front-loaded, followed by output characteristics, limitations, disclaimers, and usage guidance. Every sentence adds useful information without redundancy, which is appropriate for a paid, multi-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 complex paid operation with ten parameters, an output schema, and many siblings, the description is remarkably complete. It covers cost, prerequisites, alternatives, failure behavior, checkpoint semantics, return content categories, and a materiality disclaimer. Nothing essential is missing for an agent 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 coverage is 100%, so all ten parameters are already documented in the input schema. The description reinforces concepts like checkpoint state and prior-filing comparison, but it does not add meaningful param-specific format or interaction details beyond what the schema already provides, so the baseline score of 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?

The description states a specific action: compare new monitored filings against the prior filing of the same form and return prioritized topic-relevant changes. It clearly identifies the resource and the purpose, but it does not explicitly distinguish this tool from the sibling compare_filings or search_evidence, so it falls just short of full sibling 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?

The description gives concrete sequencing guidance: use resolve_issuer/list_filings first when coverage is uncertain, and notes that payment preflight rejects invalid or non-comparable work before charging. It does not explicitly state when to prefer this tool over direct comparison tools, so the guidance is clear but not exhaustive.

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, idempotentHint, and non-destructive, so safety is covered. The description adds important context beyond annotations: it outputs source-backed added/removed blocks (not semantic interpretation), and it explicitly enumerates missing paid features (prioritization, decision objects, checkpoint semantics, triage). However, it doesn't describe rate limits or auth needs, which is acceptable given the read-only hints.

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 core action and return, followed by a clear negation of paid features. Slightly dense with the list of missing features, but no fluff and every 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?

Given output schema exists, return values needn't be explained. The description covers the essential comparison behavior and distinguishes from a paid variant, but doesn't mention any prerequisites (e.g., both filings must exist, same issuer enforced) beyond 'same issuer'. With full schema coverage and output schema, this is nearly complete but leaves a small gap around error conditions or issuer matching behavior.

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 schema fully documents all parameters including item, limit, left, right, and identifier. The description adds no parameter-level meaning beyond what's in the schema, so 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 the specific verb (compare), resource (two filings from same issuer), and return type (source-backed added and removed disclosure blocks). It also clearly distinguishes itself from the paid operation by listing what it does NOT do, which helps an agent differentiate from siblings like check_disclosure_changes.

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?

Clearly establishes the context (comparing two filings from same issuer) and distinguishes from a paid alternative, but does not explicitly state when to choose this free primitive over siblings like check_disclosure_changes or build_disclosure_matrix. It provides clear boundaries but no positive selection guidance beyond 'lower-level free comparison primitive.'

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/openWorld semantics. The description adds genuinely new behavioral traits beyond them: that the operation is 'free' (cost model) and that results carry 'explicit coverage limits' (partial-result semantics). Cost and coverage transparency are meaningful additions not present in 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?

Two dense, front-loaded sentences with no filler; the primary listing behavior leads and the usage instruction follows. Slightly penalized because phrases like 'checkpoint coverage' carry domain-specific opacity without 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-value explanation is unnecessary, and annotations cover the safety profile. The description supplies the key missing context an agent needs — that this is the free confirm-before-buying step — making it largely complete for a listing tool.

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 all four parameters (forms, limit, history, identifier) are already documented in the schema. The description alludes to 'requested forms' and history via 'bounded historical', but adds no syntax or format detail beyond the schema. 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?

Specific verb+resource ('List ... SEC filings') with scope modifiers ('recent or bounded historical') and stated return content ('canonical source metadata and explicit coverage limits'). It implicitly contrasts with a paid 'disclosure-change check', which loosely differentiates it from siblings, but does not name an alternative tool 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?

Explicitly states when to use it: as a free pre-check to 'confirm the requested forms and checkpoint coverage before buying a disclosure-change check.' This gives clear context and an ordering against a downstream paid operation, though it does not state explicit when-not 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 cover safety (readOnly, idempotent, non-destructive) and open-world scope. The description adds genuinely non-structured context: it withholds the reconciled value, source values, and derivation arithmetic, and signals a gated paid operation behind it. It does not cover failure/error semantics, 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?

Two dense sentences, front-loaded with what the tool is and followed by what it validates and what it withholds. No filler.

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-value detail is unnecessary, and the description covers scope, the operation it gates, and disclosure boundaries. It omits what happens when validation fails, which would help an agent interpret outcomes.

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 each required parameter (cik, anchor_accession, metric, period_start, period_end) is already documented in the schema. The description only names the validated categories without adding format, syntax, or edge-case meaning 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?

States a specific verb (applicability check / validates) on a defined resource (a quarterly financial-fact reconciliation), and explicitly ties itself to the sibling operation it precedes. The free/paid distinction plus the list of validated inputs lets an agent separate this from reconcile_financial_fact 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?

The framing as a free preflight for the $1 reconcile operation makes the when-to-use condition clear: call this before paying for reconciliation. No explicit when-not-to-use or named alternative is given, but the context is unmistakable.

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 read-only/idempotent safety profile, and the description adds substantial context beyond them: the $1.00 USD commercial model, the abstention-before-payment behavior ('Returns a number only when deterministic context compatibility is established; otherwise abstains before payment'), and the validation/provenance guarantees. This is exactly the kind of pricing, failure-mode, and auth context annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each carrying distinct information (capability, abstention semantics, routing guidance), and the preflight instruction is placed last where an uncertain agent needs it. The opening '$1.00 USD specialist operation when commerce is active' is slightly cryptic and front-loads pricing over purpose, costing a point.

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-value structure needn't be explained, and the description covers the commercial trigger, the abstention condition, and the eligibility escape hatch. It is nearly complete, though the vague 'when commerce is active' qualifier and lack of detail on what a failed/abstained call returns leave a small 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 all five parameters (cik, metric, period_start/end, anchor_accession) are already documented in the schema, including the enum values the description repeats. The description adds no format, default, or boundary details beyond what the schema provides, 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?

The description states a specific verb+resource ('Return the correct standalone-quarter revenue, net income, or operating cash flow as reported through SEC filings') and enumerates the exact metrics, so an agent can distinguish it from sibling tools like build_evidence_pack or compare_filings. The anchoring mechanism (cumulative-period subtraction) further narrows its scope.

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 names when to route elsewhere: 'Use filedproof.preflight_financial_fact or POST /v1/research/financial-fact/preflight first when eligibility is uncertain.' That is a concrete precondition naming an alternative. It stops short of stating when NOT to use the tool (e.g., non-quarterly periods or unsupported issuers), so it is clear but incomplete.

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 open-world behavior. The description adds the data source (official SEC company dataset), which is useful provenance context, but it does not describe ambiguity handling, match selection, or failure modes for a resolver.

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 action and scope, followed immediately by the usage condition. No filler or redundant restatement.

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 is simple (one fully documented parameter), an output schema exists, and annotations cover the safety profile. The description supplies purpose and a usage condition, which is sufficient for an agent to select and 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 coverage is 100% and the single parameter's description already lists ticker, CIK, and exact SEC company name. The tool description repeats those same identifier forms without adding syntax, format, or precedence guidance, so it provides no meaning 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?

States a specific verb (resolve) and resource (issuer via ticker/CIK/exact name against the SEC dataset). It is clearly distinguishable from all sibling tools, which focus on filings, evidence, disclosures, and comparisons rather than identity resolution.

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 to use it before research when issuer identity is uncertain, giving a clear context for invocation. It does not name when-not-to-use or alternatives, but no sibling offers an equivalent resolver, so the condition is sufficient.

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, open-world behavior, so the safety profile is covered. The description adds meaningful context beyond that: the return type (evidence.v1 records with provenance) and the semantic caveat that lexical relevance is not a truth verdict, which guards against over-interpreting 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 sentences, zero waste, front-loaded with the core purpose followed by the return contract and the relevance caveat. 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?

An output schema exists, so return formatting need not be explained; the description still names the record type for orientation. All parameters are schema-documented and annotations cover the safety profile. Only the routing between search and the sibling build/verify tools is left implicit, 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?

Schema description coverage is 100%, so all eight parameters (q, item, forms, limit, filings, history, section, identifier) are already documented in the schema with defaults and bounds. The description adds no parameter-level syntax or guidance, 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 (find) and resource (lexically relevant primary-source evidence across SEC filings), and explicitly disambiguates from sibling verify_claim by noting 'relevance is not a truth verdict'. An agent can distinguish this from build_evidence_pack and compare_filings without opening schemas.

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: the phrase 'relevance is not a truth verdict' hints that truth-checking belongs to verify_claim, and 'bounded set' signals scope. However, no explicit when-to-use/when-not or named alternative is given, leaving selection between this and build_evidence_pack or build_disclosure_matrix 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 already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds that results are conservative, that stance signals are deterministic, and that SEC filings establish only what the company reported, not independent real-world truth.

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 operation and verdict scope. Every sentence adds distinct value with no filler.

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 and full parameter descriptions, the description need not explain return values or parameter defaults. It covers the purpose, verdict semantics, and epistemic scope, though it omits usage context relative to sibling tools.

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 schema documents all 8 parameters, including defaults, limits, and optional filters. The description adds no parameter syntax or behavioral meaning beyond what the schema provides.

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?

Specific verb (assess) plus resource (official SEC filing evidence) and object (claim), with explicit verdict categories. This is distinct from sibling tools like search_evidence or compare_filings, which retrieve or compare rather than render a support verdict.

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 guidance and no alternatives named. It describes the operation but not when to prefer it over search_evidence, build_evidence_pack, or other siblings.

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