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

The description explicitly discloses READ-ONLY behavior, confirms no order placement or fund movement, mentions response caching (~300s), outlines authentication requirements (X-Api-Key or x402 payment proof), cost per successful call, rate limit, and tier. This goes far beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) and provides crucial operational context. No contradictions with 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 fairly long but well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Returns, Guidelines, Tags). It front-loads the primary purpose and each sentence carries operational value. However, there is redundancy: the 'Purpose' section repeats the opening sentence almost verbatim, and the first sentence includes 'Call cc.auto_fetch_market_data' as an imperative. Minor deduplication would make it cleaner.

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?

The description covers all relevant non-obvious aspects: return format (multi-section with technical indicators, OHLCV, microstructure, news), authentication and payment requirements, cost, rate limiting, caching, and usage guidelines. The output schema exists but the description still gives a high-level summary of the response sections, making the tool's behavior fully predictable for an agent.

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 100%, so the parameters are already documented. The tool description adds context for the __x_payment parameter by explaining it's for x402 payment proof when retrying after HTTP 402, but it doesn't describe symbol/timeframe semantics beyond the schema. With full schema coverage, a baseline of 3 is appropriate; the description does not need to repeat parameter details.

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 is an 'All-in-one market intelligence' aggregator explicitly listing its components: OHLCV candles, computed indicators, Coinglass OI, and news via Tavily. This distinguishes it from sibling tools like cc.market_news or cc.coinglass_data, which each cover a single data source. The verb phrase 'fetch market data' plus the explicit composition makes the purpose unmistakable.

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?

Provides explicit guidance: 'Compute / parse / backtest only — no live orders' and directs the agent to feed outputs into cc.agent_strategy with force_paper=true for paper trading. This defines when to use the tool (gathering comprehensive context) and how it relates to an alternative action (trading via a sibling tool). The 'Everything an agent needs in one call' also implies it should be preferred over narrower market-data siblings.

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