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

Annotations only declare readOnlyHint/destructiveHint/openWorldHint; the description adds genuinely useful uncovered context: a prepaid credit model at 0.0005 USDT per 100 rows, a required signing/payment bootstrap via orbitpay_info, and an alternative per-request x402 payment route at 0.01 USDC on Base. That is real behavioral disclosure beyond structured fields, though it omits any note about pagination behavior despite the cursor/limit parameters.

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?

Three sentences, no obvious padding, and every sentence carries information. However, the lead sentence is a bare four-word fragment while the pricing/payment logistics occupy the bulk of the text, so the front-loading favors billing over the actual capability.

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?

There is no output schema and no description of the returned supply data, and five undocumented parameters are left entirely unexplained. For a paid data-query tool with nested filters and cursor paging, the definition covers commerce but not the query and result contract an agent needs to call 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?

Schema description coverage is 0% across five parameters (to, from, limit, cursor, and a nested free-form filters object with additionalProperties string), meaning the schema explains nothing. The description mentions none of them, so an agent has no guidance on the semantics of the range fields, the 200-row cap, cursor paging, or what filter keys are legal. With zero compensation for a 0% coverage gap, this is a 1.

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 says it is 'premium token supply data,' which identifies the resource (token supplies) but never states what the tool actually returns or the shape of that data, and the sibling set contains close candidates like get_token, list_tokens and get_token_prices that are not distinguished. Roughly half the text is spent on payment mechanics rather than purpose, so the agent learns the pricing before it learns what the tool does.

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 gives operational routing ('call orbitpay_info', or pay per request via x402 on the HTTP route), which tells an agent how to get access but not when this tool is the right choice versus get_token/list_tokens. There is no statement of when-not to use it, no prerequisite for the non-wallet case, and no condition that selects it over its siblings.

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