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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered structurally. The description adds genuinely non-schema behavior: per-call cost of $0.08 USDC (or credits) and the requirement that payment headers (X-Payment / X-Payment-Tx / Authorization: Bearer fg_…) go in the MCP request headers rather than in arguments. That is useful operational context, though it says nothing about pagination, rate limits, or failure modes when payment is missing.

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 content is duplicated almost verbatim in English and Chinese, and the payment/vendor block is repeated in both languages, roughly doubling length without adding information. The dangling "参数同左" wastes a clause, and the opening question is not the clearest lead for a curve endpoint. Some of the returned-field enumeration is useful, but the packaging is inefficient.

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 output schema, the field list (days, mark price, basis points, annualized, OI, term-structure summary) is a real contribution. However, for a paid, parameterized endpoint the definition leaves the two arguments' domains undefined and the sibling routing unresolved, which are exactly the gaps an agent cannot recover from structured fields.

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 burden, and it only lists the parameter names ("Args: currency, top") without meaning. It never says which currencies are valid, nor what `top` counts or orders (top-N expiries? top-N by open interest?), and both parameters are optional with null defaults, which is unexplained. This is effectively a restatement of the schema keys.

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 does name the resource and the payload shape ("full: every expiry days, mark price, basis points, annualized, OI"), which tells an agent this returns a curve rather than a single point. But the lead phrase "what is the futures basis right now" describes a snapshot, which is closer to what the sibling `derivatives-basis.basis_now` presumably does, so the only differentiator is the ambiguous word "full". The purpose is inferable but not crisply separated from its sibling.

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?

There is no statement of when to choose this over `basis_now` or any other sibling, and no exclusions or prerequisites beyond the payment note. The phrase "参数同左" ("parameters same as the left/previous") is a dangling cross-reference to a document the agent does not have, so it conveys no usable guidance. The agent must guess that "full curve" means use this one when all expiries are needed.

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