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

With no annotations, the description carries the behavioral disclosure burden. It reveals that responses always include population and coverage, defines coverage semantics, and explicitly prohibits performance fields as sort keys because '排序即排名'. It could also state read-only guarantees or error behavior, but the non-obvious contract is well covered.

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 front-loaded with the core purpose and a worked example, then moves to syntax, output guarantees, and constraints. The final English sentence is somewhat redundant with the Chinese opening, but the overall structure is efficient and readable.

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 there is no output schema, the description documents the key return fields (population, coverage), the supported aggregate functions, and an important ranking-policy constraint. It is complete enough for typical calls, though the exact response shape for aggregate results is left implicit.

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 the baseline is 3, but the description adds real value beyond the schema by explaining where syntax ('field operator value' joined by 'and'), the aggregate vocabulary, and the meaning of population/coverage. Some details like limit and universe sourcing are left to the schema, but the added semantics justify a score above 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?

States a clear action ('Filter a universe and aggregate over the matched set') and enumerates the supported aggregate functions, so an agent can tell this is a grouped-query tool. It does not explicitly distinguish itself from sibling tools like data_point or data_series, which keeps it from a 5.

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?

Provides a concrete worked example ('fee<=0.4 and type=passive' with median fee) and explains the where grammar and the sort restriction on performance fields. It gives clear context for when the tool is appropriate, though it does not explicitly describe when to prefer an alternative sibling.

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