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

Annotations already declare readOnly, idempotent, openWorld and non-destructive. The description adds genuinely new behavioral context: per-call price ($0.07 USDC), the upcharge for the full surface, and, critically, that payment credentials go in MCP headers (X-Payment / X-Payment-Tx / Bearer fg_…) rather than in parameters. That auth/billing disclosure is exactly what annotations cannot convey.

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 English opening is well front-loaded and efficient, and the payment-header note is useful. However, the definition then duplicates the same pricing and arg list in both [zh] and [en] blocks, and the arg list in the [zh] line adds no information over the [en] line, making the whole noticeably longer than its content warrants.

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 read-only tool with no output schema, the description does cover the return contents well (ATM IV, 25d skew per expiry, index price, timestamp) and the billing model. What is missing is the ambiguity on the three optional parameters—especially 'top' and 'expiry' formats—which the description leaves entirely unexplained.

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% for all three parameters. The description merely lists the names 'currency, expiry, top' with no added meaning—it never explains what 'top' does (top-N expiries?), what formats 'expiry' accepts, or whether 'currency' is required to be BTC/ETH. With zero schema coverage and no compensating explanation, an agent cannot confidently populate these fields.

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 sentence states a concrete resource and shape: ATM implied vol and 25-delta skew for every listed expiry, plus index price and timestamp, framed by a realistic question. It distinguishes itself from the deeper product ('full vol surface ... is $0.02'), though it never names the specific sibling tools (vol_snapshot / vol_surface), leaving the routing implicit.

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 example question ('what is the BTC option IV term structure today') implies the usage context, and the 'Entry tier' vs $0.02 full-surface note hints at when this is the cheaper choice. But there is no explicit 'use this when X, use vol_surface when Y' routing statement, and no stated preconditions.

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