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

Annotations cover read-only/idempotent/non-destructive. Description adds valuable access-tier behavior: without an API key only last 7 trading days with a 1-day delay, and include_funds requires a key. This goes beyond annotations by disclosing rate/access limits.

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 what the tool returns and ordering, then the API-key constraint. No wasted words.

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?

Covers scope, ordering, and access-tier limitations, which is important for a read tool with restricted access. Without an output schema, it would help to briefly mention the return shape (e.g., net flow values per day), but annotations and schema carry most of the load.

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 parameters and enums are already documented. Description adds minor context (newest first) but does not expand on parameter semantics 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?

States a specific verb+resource: daily total net flows for US spot BTC/ETH ETFs, newest first. Clearly distinguishable from date-range and summary siblings by its 'latest/most recent' scope. Missing only explicit mention of the sibling alternatives.

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?

Implies use case (recent daily flows) but does not explicitly say when to use this vs get_etf_flows_by_date_range or get_etf_flow_summary. The API key caveat gives some context on access conditions, but no exclusions or alternative routing.

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