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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: 'Read-Only. Does not place orders, move funds, or mutate your exchange account.' It also discloses caching (~2700s), authentication, cost ($0.003 USDC), and rate limit (30/min). This fully informs the agent about side effects and constraints beyond annotations.

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 description is verbose and repetitive, e.g., it restates the same information in the opening sentence and the 'Purpose:' field. It includes a long list of tags and redundant phrasing. Although it contains necessary details, the structure could be more concise and front-loaded. Every sentence is not clearly earning its place.

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?

Given the tool's complexity (aggregates multiple data types) and the presence of an output schema, the description covers all necessary context: it explains return type ('Normalized market microstructure data'), caching, auth, cost, rate limiting, and usage guidelines. No gaps remain for the agent to safely invoke the tool.

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 coverage is 100% with two parameters: symbol and __x_payment. The description adds meaning beyond the schema by noting symbol defaults to 'top 20' and explaining __x_payment as an alternative for HTTP authentication. While the schema already covers basics, the description enriches parameter understanding. Baseline 3 due to high coverage, +1 for additional context.

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 clearly states the tool provides 'Comprehensive Coinglass derivatives data including open interest, liquidations, funding rates, and long/short ratios.' This specifies the verb (provides) and resource (aggregated derivatives intelligence). However, it does not explicitly differentiate from sibling tools like cc.open_interest or cc.funding_rates, which may offer more focused data. The purpose is clear but not perfectly distinguished.

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 description provides explicit guidance: 'Use for research / signal context. Pair with cc.agent_strategy (paper) before any live order. Do not invent fills from this data alone.' It also warns about caching (45-min) and authentication requirements. This clearly tells the agent when and how to use the tool, and when not to rely on it.

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