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

Annotations already cover read-only, idempotent, non-destructive, so the bar is lower; the description still adds meaningful behavior: rows are dated with the days they cover, no single-day return exists so today's movers are flows, min_assets_usd exclusion applies only to the return lists, and leveraged funds are flagged. That is substantive beyond the annotation set, though it does not say how many lists come back or whether lists can be empty.

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?

Front-loaded with the purpose, then scope, then filters, then next steps – a sensible order with no filler sentences. It is a dense, slightly run-on single paragraph, and the two window enumerations make it longer than strictly necessary, but each clause carries 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 no output schema, the description does the work of telling the agent it gets dated rows across flow and return lists with leveraged flags. The only real gap is that the exact return shape (number of lists per call) is only implied rather than stated.

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% and the description compensates fully for all six parameters: enumerates the flow_window values and its 1D default, the return_window values and its 1M default, the desk and category value sets that the bare string schema omits entirely, the min_assets_usd default of 100,000,000, and limit's 1–25 range with default 10.

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?

Opens with a specific framing ('what moved') and then names the exact resources: biggest fund inflows and outflows over a flow window plus best/worst total returns over a return window. The distinction from siblings like etf_flows and etf_rankings is implicit in the two-sided ranking-plus-flows framing, and the 'today's movers are the flows' note makes the intent unambiguous.

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?

Explicitly positions itself as the entry point of a workflow ('Start a daily scan here, then etf_profile or etf_risk_check on a name that stands out'), which is real routing guidance to named alternatives. It does not, however, state when to prefer this over the sibling etf_flows tool, leaving one obvious overlap unresolved.

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