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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond these: it states 'Read-only public research data,' 'No account access, no order placement or fund transfers,' and 'Not investment advice.' This gives the agent a better sense of the tool's safety and purpose without contradicting the annotations.

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 compact yet dense, using only a few sentences to pack the core purpose, optional behaviors, a routing pointer, and safety disclaimers. It is front-loaded with the main action and then proceeds to details, with no filler. Every sentence earns its place.

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?

Given the tool's complexity (11 parameters) and the presence of an output schema, the description provides sufficient orientation: it explains the scope modes, flow/event options, and the distinction from TVL history. The safety and public-data nature are also covered. There is no obvious missing information that an agent would need to invoke it 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 schema covers 100% of parameters, so the baseline is 3. The description adds value by explaining how parameters interact: e.g., 'scope=full adds por,' 'include_flows=true returns flows.series[],' and 'include_history=true returns precomputed comparison fields only, not raw historical snapshots.' This contextualizes the combination rules beyond individual parameter descriptions, raising it above the baseline.

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 and resource: 'Exchange reserve snapshots by venue and asset.' It immediately conveys what the tool does and distinguishes it from related tools by noting 'TVL history→get_platform_history.' This is far from a tautology and clearly differentiates it from siblings like get_platform_history or get_cex_orderbook_depth.

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 an explicit routing hint: 'TVL history→get_platform_history,' which tells the agent when to use an alternative. It also outlines optional parameter combinations (scope=full, include_flows, include_events) that clarify when those are applicable. It does not state exhaustive 'when not to use' conditions, but the guidance given is clear and actionable.

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