bridge_flow_history

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

With no annotations, the description carries the behavioral disclosure burden, and it does a good job: it reveals the data source (LI.FI API, 9+ protocols), DB-backed storage, 5-minute cache, 365-day retention, permanent monthly archive, and the exact one-row-per-day shape. It stops short of documenting failure modes or rate limits, but for a simple read-only history endpoint it discloses the relevant operational behavior.

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

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

The content is front-loaded and logically ordered, but the first portion repeats itself: the summary of fields is given twice, once in the opening dash phrase and again in the 'One row per day' sentence. A single consolidated sentence plus the caching/retention note would be more compact without losing 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?

For a tool with one parameter and no output schema, the description is complete: it explains what data is returned, what each row contains, how fresh the data is, where it comes from, and how long it is retained. An agent has enough context to invoke the tool correctly and interpret the result. No critical operational detail 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?

The only parameter, days, is already fully described by the schema (1–90, default 30), and schema coverage is 100%, so the baseline is 3. The description adds only the redundant 'up to 90 days' phrase and does not contribute new meaning beyond what the schema already states.

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 opens with a specific verb-resource combination: 'Get daily cross-chain bridge flow history', and immediately specifies the return fields, granularity ('One row per day'), and max window ('up to 90 days'). The 'history' framing and daily aggregation distinguish it from the sibling 'bridge_flows' tool, even though the sibling is not named explicitly.

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 says it is 'useful for tracking cross-chain capital flow trends', which implies a use case, and provides context like 5-minute caching and 365-day retention. However, it does not explicitly say when to reach for this tool over bridge_flows or the many historical siblings, nor does it state exclusions or edge cases.

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