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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered; the description adds genuinely non-obvious operational context: metered billing at $0.5 USDC per call and the requirement to pass X-Payment / X-Payment-Tx / Authorization headers rather than parameters. That payment-header instruction is exactly the kind of detail an agent would otherwise get wrong. The gain is offset slightly by the unresolved question of how an exchange is targeted when there are no arguments.

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 hook is well front-loaded, but the body is bilingual padding: the paid-per-call pricing and "Args: none" are stated twice (zh and en), and the payment-header warning is repeated. Roughly a third of the text is redundant translation rather than new information.

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?

With no parameters, no output schema and no nested structures, the description has little structural support and must carry the load itself. It does cover content scope and payment mechanics, but omits the single most important operational fact for a zero-arg, per-exchange tool: how the target exchange is identified at call time.

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 is an empty object and the description does state "Args: none" / "入参：无", which matches. But it simultaneously instructs querying "按交易所代码" with examples BINANCE / COINBASE / BYBIT, implying a selector argument that does not exist in the schema. With zero parameters there is no schema detail to lean on, so this internal contradiction leaves the agent unsure how to scope the call to a specific exchange.

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 opening line gives a concrete verb-plus-resource framing ("which exchange is cheapest to list on") and the Chinese section enumerates the payload: fee stance, token budget, application routes, timeline, review checklist, 2026 campaign, sources. "One exchange" signals a per-exchange scope that differentiates it from aggregate siblings like exchange_overview or listing_digest. It loses a point because the same paragraph then names example exchange codes (BINANCE/COINBASE/BYBIT) as if they were inputs, muddying what the tool actually operates on.

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?

Usage is implied by the framing question and by the "one exchange" scope contrast, which suggests the per-entity counterpart to a digest or overview tool. There is no explicit statement of when to prefer this over exchange_matrix_entry or listing_digest, and no exclusions or prerequisites beyond the payment note.

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