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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered structurally. The description adds genuinely useful context beyond them: this is a paid call at $0.5 USDC (or prepaid credits), and payment must travel in request headers (X-Payment / X-Payment-Tx / Authorization: Bearer), not in parameters — a real invocation constraint the schema cannot express. It does not disclose return shape or rate limits, but for a zero-arg read the payment mechanics are the material addition.

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 payment and vendor metadata are front-loaded and actionable, but the zh/en bilingual duplication of the same payment boilerplate adds length without adding information. The trigger-question opening is also loosely coupled to the actual resource, costing clarity up front.

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 no-parameter, read-only, no-output-schema tool, the description covers what data is returned (per-exchange anti-middleman policy plus official blacklist), a concrete illustrative data point, and the full payment protocol. The main gap is the scope of exchange coverage and how results are structured, which an agent may want before calling.

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 tool has zero parameters and schema coverage is 100%, so baseline 4 applies. The description correctly reinforces 'Args: none' and explicitly warns that payment credentials belong in headers rather than parameters, preventing an agent from inventing a parameter for payment.

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 core is stated — anti-middleman policy and official blacklist per exchange, with a concrete example (Binance's 2025-12 announcement of 7 blacklisted intermediaries). But the leading frame 'Ask "which exchange is cheapest to list on"' describes a different question than the resource actually returned, which muddies rather than sharpens the purpose. No sibling differentiation against exchange_overview or listing_intel, which cover adjacent exchange-listing topics.

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 opening question supplies an implicit trigger scenario, and the closing line tells the agent how to pay. There is no when-not guidance, no mention of when another sibling tool is the better choice, and no statement about coverage or prerequisites beyond payment.

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