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?

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 declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely non-obvious traits: per-source size ceilings (4 MiB money-market, 1 MiB otherwise), a warning that source JSON is untrusted, that packets may be partial, and that no verification is performed. Those caveats materially affect how an agent should trust and handle the 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?

Four short, front-loaded sentences with no filler; the usage condition leads and the constraints follow. Slightly telegraphic phrasing ('No Evidence Carrier verification is performed') costs a little clarity 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 output schema and only one parameter, the description covers what an agent most needs: scope, size limits, trust status of returned JSON, and the possibility of partial packets. The undefined 'Evidence Carrier' term is the one piece of unexplained context.

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

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

Schema description coverage is 0% and the description never explains the single 'topics' parameter — its enum values, the 1–5 cardinality, or whether topics combine. The only hint is the passing reference to the 'money-market atlas'. The enum strings are self-explanatory, but the description does not compensate for the coverage gap as required at <50%.

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: 'Retrieve original public documents' — an agent knows this returns source documents rather than computed tables or reviews. It does not, however, name or distinguish itself from any of the eight sibling financial_evidence_* tools, 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?

'only when table detail is insufficient' gives an explicit when-to-use condition and implicitly excludes the common case where tabular results suffice (the query/dataset siblings). The alternative tool is described generically rather than named, which is a minor gap.

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 declare readOnly, idempotent, openWorld and non-destructive behavior, but the description adds genuine context: what gets returned (original product evidence, source URL, retrieval time, content hash), the caveat that prepared_response signals reviewability only and not freshness/safety/task completion, and that it carries no account or execution authority. This meaningfully extends the safety profile beyond the structured 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?

It is dense but front-loaded, leading with the action before the mode options, defaults, return payload and caveats. Every sentence conveys distinct information; the only cost is a slightly run-on flow between the mode list and the return/caveat clauses.

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 read-only annotations supplied, the description need not detail return structure or safety, yet it still covers modes, selection formats, the default, and the limits of prepared_response. Nothing an agent needs to invoke 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 0%, so the description carries the full burden, and it largely delivers: it maps each enum value to a selection format ('institutions, one to five slugs, for example au-sfb'; 'exit, one to four USD sizes, for example 10000,100000') and notes the default for empty input. The 'funding (selection: USD)' phrasing is cryptic about the actual expected format, leaving one mode under-specified.

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

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

The description states the action (run a financial-evidence workflow) and enumerates the three concrete modes (funding, institutions, exit), so an agent knows what the tool produces. However, it frames the purpose by reference to an external product ('the same task as the public Research Desk and REST API') rather than with a self-contained verb+resource, and it does not differentiate itself from the many financial_evidence_* siblings.

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 explains how to choose among the tool's own workflow modes and what an empty selection does, which is implicit usage context. It gives no guidance on when to pick this tool versus sibling tools such as financial_evidence_query, financial_evidence_review or financial_evidence_agent_query, so an agent must infer the routing.

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