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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds real behavior beyond them: it is a free tier with a daily per-caller quota, and payment credentials must be passed via X-Payment / X-Payment-Tx / Authorization headers rather than parameters. It does not say what happens when the quota is exhausted, which keeps it from a 5.

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 same content is restated three times (the inline Chinese summary, the [zh] block, and the [en] block), which doubles the length without adding information. The useful payload and the payment-header caveat are buried in the middle and end rather than front-loaded.

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 three entirely undocumented parameters, no output schema, and an open-world annotation, the definition should explain parameter effects and result shape. It lists the returned metrics but leaves the inputs opaque and says nothing about error or quota-exceeded behavior.

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 description coverage is 0%, so the description carries the full burden, yet it only lists the parameter names (symbol / top / chain) and notes they are optional. It never explains what 'top' means (a count? a ranking depth?), what chain values are valid, or how symbol filtering interacts with the aggregate metrics.

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 names a specific resource and enumerates what it returns: total stablecoin supply, 7d net flow, top-4 share, and top-3 detail, framed by the question 'where is stablecoin supply moving'. It does not differentiate itself from the sibling stablecoin-flow.flow_report, so it stops short of 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the obvious alternative (stablecoin-flow.flow_report) even though the sibling exists. Usage is only implied by the framing question, and the only concrete guidance is about billing headers, not about selecting this tool.

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