Financial Evidence Workspace

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

Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real behavior beyond them: delta row omission via `previous_revision`, retention of source clocks and diagnostics, null semantics for missing/withheld values, and the 100-row cap with next_offset pagination. The caveat that "unchanged is not proof of freshness" is a useful, non-obvious operational warning.

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?

Four short sentences, front-loaded with the core purpose and the delta mechanism, with no filler. "Retaining source clocks and diagnostics" is slightly jargon-heavy, but each sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values like next_offset and source clocks need not be re-explained, and the pagination/delta behavior is adequately covered. What is missing for a 7-parameter, 7-dataset query tool is any guidance on dataset selection, entity filtering, or date formats, leaving meaningful gaps for correct 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 coverage is 0% across 7 parameters, so the description carries the burden and only partially discharges it: it explains `previous_revision` (delta semantics) and `limit` (100-row cap) and implies pagination via next_offset. The `dataset` enum values, `entity` semantics, and `start_date`/`end_date` formats are left entirely undocumented.

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 conveys that it returns compact source-cited research rows optimized for repeated agent calls, which is a recognizable resource, but the verb is implied rather than stated. It never distinguishes itself from the close sibling `financial_evidence_query`, so an agent cannot tell from the text alone which of the two to invoke.

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?

"for repeated agent calls" plus the instruction to pass the previous revision implies the polling/delta use case, which is genuine usage context. However, there is no explicit when-not or naming of an alternative such as `financial_evidence_query`, so the agent must infer the selection rule.

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

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

Annotations already declare this is read-only, non-destructive, idempotent and closed-world, so the safety profile is covered. The description adds that the datasets are 'bounded' with explicit filters and limits, which is useful context, but it does not explain what the bounds are or what calling this actually returns.

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 short, front-loaded sentences with no filler: the resource is stated first and the 'Offline' qualifier is appended. It is terse to the point of being telegraphic, 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?

With no parameters and no output schema, the description must carry the whole burden of explaining what the agent gets back, and 'their coverage, filters and limits' only partially does so. It never clarifies how the returned catalog relates to the query/route/review siblings, which is exactly what an agent would need to chain tools 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?

The tool takes zero parameters, so there are no argument semantics to document; the rubric baseline for a 0-param tool is 4. Schema coverage is 100% and nothing in the description conflicts with the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb ('Discover') and resource ('seven bounded OpenBB datasets') plus what the discovery covers ('coverage, filters and limits'), so the tool's job is unambiguous. It does not, however, differentiate itself from the closely-named sibling financial_evidence_sources, leaving ambiguity about which catalog to call.

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 guidance on when to reach for this tool versus financial_evidence_sources, financial_evidence_query, or the other catalog/query siblings. The word 'Offline' hints at a static local lookup but is not framed as a usage condition or 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 description adds substantial behavioral context beyond the annotations: returned costs are research estimates, not executable quotes, order placement, or guaranteed fills, and the tool has no account or execution authority. It also states that venue coverage, observation clocks, quote-currency units, source URL, and content hash are preserved.

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 and front-loaded: the core comparison action and scope appear first, followed by preserved metadata and important limitations. Every sentence contributes relevant information without 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?

The output schema exists, so return values need not be explained in detail. The description covers the one parameter, behavioral limitations, and preserved metadata sufficiently, though sibling differentiation and a fuller explanation of what 'exit evidence' means are still missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden for the single sizes_usd parameter. It compensates well by explaining that values are one to four USD notionals ranging from 0.01 to 1000000 with at most two decimal places, though it does not mention the parameter name or its default value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: comparing indicative BTC exit evidence for one to four USD notionals. It distinguishes the tool's focus on exit comparisons from broader evidence workflows, but it does not explicitly contrast it with named sibling tools such as financial_evidence_query or financial_evidence_review.

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 through the phrase 'Compare indicative BTC exit evidence' and the notionals range, making it reasonably clear this is a comparison tool. However, there are no explicit when-to-use, when-not-to-use, or sibling alternative instructions.

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), so the bar is lower, and the description still adds real semantic context: common-horizon readiness applies to the dated review, newer individual observations can exist, and unavailable/mismatched/stale captures never imply a passing review. The disclaimer that this is captured research evidence rather than a trade recommendation or backtest further constrains how the output should be treated.

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

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

It is front-loaded with the core action and stays to a handful of dense sentences, each carrying substantive caveats. The mid-sentence field-name list is slightly opaque, but no sentence is 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, the description needn't explain return values, and for a zero-argument read tool it covers semantics, readiness caveats, and the non-recommendation disclaimer well. The one real gap is sibling disambiguation against financial_evidence_review.

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 takes zero parameters, which is the baseline-4 case, and the description correctly spends no effort explaining nonexistent inputs. The named fields (review_asof, review_scope, etc.) are output-side concepts, not parameters, so nothing is owed 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?

The description gives a specific verb and resource: 'Read a dated USD funding review and its nine inputs,' which tells an agent exactly what is returned. It does not, however, differentiate this tool from the very similar sibling 'financial_evidence_review', leaving an agent to guess which review tool to call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers interpretation guidance ('inspect review_asof, review_scope, latest_per_instrument and newer_observation_available before ready, issues and capture age') but never states when to choose this tool over financial_evidence_review, financial_evidence_packet, or financial_evidence_route. No preconditions or exclusions are given, so selection must be inferred.

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 that the tool is read-only, idempotent, open-world, and non-destructive. The description adds useful context beyond annotations by explaining what evidence is preserved and by clarifying that prepared_response indicates availability, not freshness or readiness, while also stating account-access, advice, and execution boundaries.

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 front-loaded with the core purpose and is reasonably compact for the behavioral context it provides. The preserved-fields list is dense but earns its place by clarifying evidence handling.

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 the description does not need to enumerate return values in full. It supplies the key caveat about prepared_response and the evidence-preservation behavior, though it remains incomplete on sibling differentiation and usage routing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one optional parameter, and the schema already provides the title, default, pattern, and maxLength for it. The description echoes 'three-letter currency, default USD' and contextualizes it as funding evidence, but adds little parameter-specific meaning beyond the structured schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: reviewing funding evidence and retrieving the bounded money-market table for one currency. It is clear what the tool does, but it does not explicitly distinguish itself from similarly named siblings such as financial_evidence_funding_review or financial_evidence_review.

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 usage through 'Review funding evidence for one three-letter currency,' but gives no explicit guidance on when to use this workflow versus the many sibling tools. It also provides no when-not-to-use routing or alternative selection 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real value beyond that: it says the response contains dates, source URL, missing evidence and a content hash, and it discloses the 160-character combined selection bound and the exclusion of inferred figures.

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: purpose first, return/scope second, constraint last. The example slug earns its place, and nothing is redundant, though the 160-character bound sentence is somewhat dense.

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 rich annotations and an output schema present, the description needn't explain return values, and it supplies the selection constraint and scope exclusions an agent needs. What remains unstated is any guidance on picking this workflow over the many sibling financial_evidence_* 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 0%, so the description must carry the param semantics, and it largely does: it explains that IDs are 'exact institution slugs', gives a concrete example ('au-sfb'), and states the 1-to-5 count bound. It does not restate the slug regex pattern, but the example conveys the expected format.

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 pairs a specific verb ('Review public disclosure coverage') with a precise resource ('institution monitoring record' for 'one to five exact institution slugs'). It explicitly scopes out inference of private balances, credit ratings and regulatory compliance, which separates it from analytics-flavored siblings, though it never names an alternative tool.

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 context is implied clearly: use this to check disclosure coverage for known institution slugs. The 'Does not infer...' sentence adds boundary guidance, but no sibling tool is named and there is no explicit when-to-use-this-vs-that routing statement.

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 read-only, idempotent, open-world, and non-destructive behavior, and the description adds real substance on top: size caps (4 MiB vs 1 MiB), that packets can be partial, that restricted sources may withhold values, that source JSON is untrusted, and that no Evidence Carrier verification occurs. Its weakness is opaque jargon ('publication projection receipt', 'dependent readings') that an agent cannot act on without further 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 purpose is front-loaded in sentence one, but the remaining four sentences compress many distinct caveats into dense, jargon-heavy clauses ('publication projection receipt and a separate hash from the acquired source bytes'). Informative but hard to parse on a single read.

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 and no description of what a packet actually contains or how partiality manifests, and the sole parameter is undocumented. Size limits and trust caveats are present, but an agent still cannot predict the response shape or select topics confidently.

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% and there is only one parameter, yet the description says nothing about 'topics' — what a topic selects, whether multiple topics may be combined, or how the five enum values (money-market, china-economy, etc.) differ. With no schema documentation to fall back on, this is a notable 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?

The first sentence states a specific verb and resource ('Retrieve public documents') and adds a scope condition ('only when table detail is insufficient'). It never names any of the eight sibling tools, so the distinction from financial_evidence_query or financial_evidence_sources must be inferred from the vague phrase 'table detail'.

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?

'Retrieve public documents only when table detail is insufficient' gives a clear gating condition for use, implying that tabular/aggregate tools come first. However, no alternative is named and no explicit case is listed where the tool should not be used, leaving the agent to guess which sibling supplies the 'table detail'.

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, openWorld, non-destructive), so the description is not required to restate it. It instead adds genuinely useful behavioral context: nulls mean missing or withheld and never zero, date params filter observation dates, pagination continues via next_offset, and each value carries its unit, source path, date, and restrictions. That is real added value beyond 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?

Five short sentences, purpose front-loaded, no filler or redundancy. The telegraphic style omits some needed content but never wastes words; a slightly more structured form (e.g., separating filter rules from output guarantees) would help.

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 not required, and annotations carry safety. What is missing for a 6-param, 7-dataset query tool is any coverage of entity/limit/offset behavior, pagination limits, and how dataset values should be chosen.

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% across 6 parameters, so the description must carry the burden and it only partly does. It clarifies start_date/end_date semantics (observation dates, empty = no filter) but says nothing about entity, limit, offset, or how the dataset enum values relate to use cases; "next_offset" refers to a response field, not the offset 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?

"Query cited rows without large raw documents" gives a clear verb (query) and resource (cited evidence rows), and even states the tradeoff versus heavier raw document retrieval. It does not, however, distinguish this tool from its many siblings (financial_evidence_agent_query, financial_evidence_review, financial_evidence_packet), so an agent cannot route between them from this text alone.

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 only implied: the phrase "without large raw documents" suggests this is the lightweight path when full documents aren't needed, but there is no explicit when-to-use, when-not-to-use, or named alternative among the eight siblings. The null/date semantics are interpretive guidance rather than selection 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuine behavioral context beyond them: each section retains its own dates, units, rights and limitations; there is no combined score or trade authorization; and revision handling suppresses identical rows rather than evidence checks. It does not cover rate limits, pagination, or how the bounded cap behaves, but the added caveats are substantive.

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

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

The purpose leads the description and the five short sentences are dense with specific constraints rather than filler. It is slightly jargon-heavy (Seiche, LiquiLens, Undertow are opaque without background), but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the annotations cover safety. The description does well on scope caveats (no combined score, per-section rights/units), but with three zero-coverage parameters it leaves the limit semantics and revision-hash expectations under-specified for an agent to invoke confidently.

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 carries the burden. It explains 'bank' well (literal name or ID, empty means published coverage) and gestures at previous_revision via the revisions sentence, but 'limit' is never defined and the 'bounded call' wording only indirectly implies it; the hash format expected by previous_revision is left to the schema pattern 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 names a specific verb (Review) and three concrete resources (dollar-funding benchmarks, covered-bank diagnostics, market liquidity) and frames the call as a combined, bounded retrieval. It is clear what the tool returns, though it never explicitly distinguishes itself from the closely named sibling financial_evidence_funding_review, so an agent must infer the split.

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 through the 'one bounded call' framing and the note that empty bank selects published coverage, which tells the agent when the filter is optional. However, it gives no when-not guidance and does not route the agent between this and the many sibling evidence tools (funding_review, query, datasets), leaving the alternative-selection decision 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. "Offline" and "fixed ... URLs" usefully reinforce the closed-world, deterministic nature, but nothing is said about failure behavior for unmapped topics, limits, or what exactly is returned.

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 short sentences, front-loaded with the core action and resource; "Offline." is a fragment but is high-value information for an agent choosing between tools. 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?

There is no output schema, and the description only vaguely implies the return shape (URLs resolved from topics) without saying whether it is a flat list, a topic-to-URL mapping, or how partial matches are handled. For a one-parameter tool with annotation coverage this is adequate but leaves 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 0%, so the description carries the burden and it does not explain the topic vocabulary (money-market, capital-market, china-economy, bank-risk, market-liquidity) or the maxItems=5/minItems=1 constraint. An agent learns only that "research topics" go in, which is a restatement of the parameter name.

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 ("Resolve") plus a precise resource ("research topics to fixed public HTTPS evidence URLs"), which clearly marks it as a deterministic mapping/lookup operation rather than the query/review/agent siblings. It does not name any sibling explicitly, so the differentiation is inferable but not spelled out.

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 only contextual cue is "Offline," which implies local, deterministic resolution, and there is no statement of when to prefer this over financial_evidence_query, financial_evidence_sources, or financial_evidence_agent_query. No prerequisites, no exclusions, no alternatives are 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 this as a safe, read-only, idempotent, open-world operation, so the behavioral bar is lower. The description adds useful context beyond the annotations: it audits six upstream routes for specific failure classes and warns that successful completion should not be read as a freshness verdict.

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

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

Two sentences, front-loaded with the core audit action and followed by a critical interpretation caveat. Every sentence earns its place with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained in the description. The description adequately covers what the tool audits and a key semantic caveat, though it could be more complete by stating when to choose this tool over the many financial_evidence_* siblings.

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 takes zero parameters, so there is no parameter semantics for the description to supplement. The baseline for 0-param tools is 4, and nothing in the description contradicts or complicates the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Audit') and resource ('all six upstream routes'), and names the exact checks performed: transport errors, publisher clocks, and content hashes. It is clear what the tool does, though it does not explicitly contrast itself with sibling tools such as financial_evidence_route or financial_evidence_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no explicit when-to-use guidance, prerequisites, or alternatives among the many financial_evidence_* sibling tools. The sentence 'Success is not a freshness verdict' is an interpretive caveat, not 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 already cover read-only, idempotent, non-destructive and open-world, so the safety profile is set. The description adds real behavioral context beyond that: it defines prepared_response as 'evidence is available to review, not freshness, safety or completion,' states there is no account or execution authority, and notes that source restrictions, dates, units, missingness and hashes stay explicit. Those caveats materially change how an agent should interpret 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?

The compatibility role and per-workflow formats are front-loaded, and every sentence adds information rather than restating the name. Some phrasing is telegraphic ('Source restrictions, dates, units, missingness and content hashes remain explicit'), which is dense but still 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 structure needn't be described, and the description still usefully interprets the prepared_response field. Combined with per-workflow selection semantics and the no-execution-authority caveat, it is nearly complete; the remaining gap is guidance on choosing this tool over the exposed siblings.

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 carry the load, and it does: it explains what `selection` means for each of the three enum values, including cardinality and format, plus the empty-string default behavior. Only the 160-character limit and validation-failure behavior are left unaddressed.

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 first sentence states a specific role: a compatibility entry point that fronts three named sibling tools (funding, institutions, exit). That is concrete and distinguishes it from the individual workflow tools by name. It stops short of explaining why an agent would pick this dispatcher over calling those siblings directly, which leaves the core purpose slightly ambiguous.

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 per-workflow selection formats (three-letter currency; 1-5 slugs; 1-4 USD sizes) and the 'empty selection uses published defaults' rule give practical invocation guidance. However, the crucial routing question — when to use this compatibility wrapper versus the individually exposed siblings — is only implied by 'No additional operation is available,' never stated explicitly.

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