financial_evidence_fetchFetch bounded read-only JSON evidence from LiquiLens, Undertow, Seiche, and Palimpsest. Missing evidence remains unavailable, never zero or calm.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | Yes | ||
| timeout | No | ||
| max_bytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond those annotations: 'bounded' implies size/time constraints, and 'Missing evidence remains unavailable, never zero or calm' reveals how absent data is represented. This is meaningful and non-redundant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the main action is front-loaded, and the behavioral note about missing evidence is placed second. Every clause earns its place and the whole text is highly scannable for an agent.
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, so the description should clarify what evidence is returned and how to interpret it. It does mention sources and the missing-evidence behavior, but it does not explain how the topics parameter maps to evidence, what the JSON structure looks like, or how timeout/max_bytes affect behavior. The description leaves too much unknown for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting parameters, but it does not explain topics, timeout, or max_bytes. The term 'bounded' vaguely suggests limits but never maps to specific parameters. An agent cannot infer parameter semantics from the description alone, making this a significant 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 description uses a specific verb ('Fetch') and resource ('JSON evidence') from named sources (LiquiLens, Undertow, Seiche, Palimpsest), making the tool's function clear. It does not explicitly differentiate from sibling tools financial_evidence_route and financial_evidence_topics, but the action and resource are distinct enough to infer separation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus financial_evidence_route or financial_evidence_topics, and does not mention any exclusions or prerequisites. Usage context is only implicit from the tool name and the topics parameter, with no explicit routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct role: one fetches evidence, one resolves topics to sources, and one lists available topics. There is no meaningful overlap or ambiguity between them.
All tools share the consistent financial_evidence_ prefix and use a simple action-oriented suffix: fetch, route, topics. The naming pattern is uniform and predictable.
Three tools is well-scoped for a narrow read-only evidence retrieval server. Each tool serves a necessary step in the workflow: discover topics, resolve routes, then fetch data.
The domain is bounded read-only access to fixed public evidence sources, and the toolset covers the full workflow: listing what is available, resolving where it lives, and fetching it. No obvious CRUD or lifecycle gaps exist because the domain is intentionally read-only.