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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-schema behavior: the call is free with a daily per-caller quota, and payment credentials must ride in MCP request headers (X-Payment / X-Payment-Tx / Authorization: Bearer fg_…) rather than in parameters. That header-vs-parameter rule is the kind of detail an agent cannot derive from the schema.

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 useful content (formula, recompute, free, header-based payment) is front-loaded, but the payload is bloated by a duplicated Chinese/English restatement of the same facts and a vendor-asset sentence that appears to be shared boilerplate. Several sentences repeat rather than add.

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 zero-parameter, annotation-covered, read-only informational tool with no output schema, the description covers the essentials: what the content is, that it costs nothing with a quota, and where credentials go. It does not describe the response shape (prose vs JSON), but that is a minor gap at this complexity.

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 takes zero parameters, which is the baseline-4 case, and the description confirms it with "入参：无" / "Args: none", consistent with the empty properties object. No additional parameter meaning is needed or possible.

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 first line states a reasonably specific purpose: it returns the smart_score formula and how to recompute it. But the second block describes a different resource ("Vendor asset 稳定币最高收益池榜（跨链实算）"), which is the ranking product rather than the methodology document, so an agent reading the whole description could think this tool returns pool rankings. The purpose is recoverable but muddied by template boilerplate.

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 'which stablecoin pool has the best risk adjusted yield'" plus "how to recompute it" implies this is the tool to fetch for explaining or reproducing the score, which is useful implied guidance. However, it never says when NOT to use it or points to the data-returning siblings (top5, top20, by_chain) that an agent would need for actual pool results.

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