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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely non-obvious behavior on top — per-call pricing of $0.08 USDC or prepaid credits, and the critical instruction that payment headers (X-Payment / X-Payment-Tx / Bearer token) go in the MCP request headers rather than in arguments. It also discloses the report's contents, so the agent knows the shape of the return without an output schema. It does not state rate limits or failure/refund behavior on payment failure, keeping it below 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 core purpose is front-loaded and the output enumeration is efficient. However, the definition repeats itself across an English line, a Chinese line, and then a separate [zh]/[en] block restating the same paid-per-call and argument information, which is noticeable redundancy for a three-parameter tool.

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 paid, read-only report tool with no output schema and no parameter descriptions, the definition covers what an agent needs: what is returned, what is required, what it costs, and where credentials go. The remaining gap is that the optional `chain` parameter and the response format for errors or unsupported chains are unaddressed.

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 must carry the parameter burden. It does partially: it states address is required and chain/size_usd are optional, and it clarifies that size_usd is the dollar amount used to compute the impact percentage — real semantic value beyond a bare "Size Usd" number. But chain receives no explanation of accepted values or default behavior, and size_usd's units/format are only implied.

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 concrete question it answers ("how deep is the liquidity for this token") and enumerates the exact payload: top 5 pools with chain, DEX, pair, price, depth, age, plus aggregate liquidity, FDV, market cap, and price impact at a given size. That is far more specific than a restatement of the name. It does not, however, differentiate itself from the sibling `dex-liquidity.pool_summary`, so an agent cannot tell from the text which of the two to pick.

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 framing "Ask 'how deep is the liquidity for this token'" gives an implied usage trigger, and the mention of a specified dollar amount signals the impact-cost use case. There is no when-not guidance, no prerequisite conditions, and no reference to the pool_summary alternative, leaving the selection decision to inference.

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