Central Command — x402 Trading Intelligence

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

Description significantly expands on annotations by disclosing READ+WRITE behavior, that deploy without execute does not move money, default force_paper=true, auth requirements (X-Api-Key, no spoofing X-Linked-User-Id), cost implications, rate limit, and specific instruction to report real HTTP errors. This far exceeds the annotation hints.

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 dense but every sentence serves a purpose, structured logically from purpose to behavior, safety, auth, cost, returns, and guidelines. It is front-loaded with the primary purpose and uses compact bullet-like phrasing without redundancy.

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 (10 params, nested objects, output schema), the description covers all key aspects: purpose, side effects, safety gates, auth, cost, rate limit, return envelope, and usage sequence. The output schema and parameter descriptions fill in the remaining details.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by clarifying action categories (safe/read vs write vs destructive live), default force_paper behavior, and the confirm_live requirement, which helps interpret parameters. However, it doesn't detail each parameter beyond schema.

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?

States it runs the Central Command agent console covering strategy lifecycle and account actions, listing specific actions (guide/whoami, create/update, backtest, deploy, paper execute, live orders). Clearly distinguishes from sibling data-fetching tools like cc.asset_scanner or cc.coinglass_data.

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 guidelines: start with action=guide then whoami, prefer paper, and warns that live orders require confirm_live=true. However, it does not explicitly name alternative tools or specify when not to use this tool, so it falls short of a 5.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description goes well beyond by disclosing specific behaviors: it is READ-ONLY and does not place orders/move funds/mutate accounts, responses may be cached (~1800s), authentication methods (X-Api-Key or x402 payment proof), cost per call, rate limit, and return structure. This context is genuinely useful for the agent and not present in the annotations. No contradiction exists.

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 well-structured with labeled sections (Behavior, Auth, Cost, Rate Limit, Returns, Guidelines, Tags), which aids scanning. However, it is verbose and repeats the exact same purpose sentence twice, which wastes words. The length is acceptable for the amount of detail, but the redundancy prevents a higher score.

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 is complete for this tool's complexity. It covers the tool's purpose, behavior (read-only, caching), authentication, cost, rate limits, return format, and usage guidelines. An output schema exists, so return details are not needed in the description. The tool has no required parameters, and the single optional parameter is already well documented in the schema. There are no significant gaps.

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 input schema has only one optional parameter, __x_payment, with a comprehensive description already explaining its purpose (x402 payment proof for HTTP 402 retries). Schema coverage is 100%, so the description does not need to add much. The description mentions __x_payment in the auth context, but this does not add significant new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.

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's function with a specific verb ('scans'), a defined resource (36 major crypto assets across BTC, ETH, SOL, alts, and memes), and a precise scope (multi-timeframe technical signals including RSI, MACD, Bollinger Bands, ATR, and composite scores). This distinguishes it from sibling tools like cc.central_signal or cc.indicator_generator by asset coverage and output type. The only minor flaw is the duplicated purpose sentence, but the clarity is unambiguous.

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 usage guidance: 'Use for research / signal context' states when to use, 'Pair with cc.agent_strategy (paper) before any live order' names an alternative/companion tool, and 'Do not invent fills from this data alone' gives a clear exclusion/caution. This is more than sufficient for an agent to decide when to invoke this tool.

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

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.

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

The description goes well beyond the annotations by disclosing caching (~60s), authentication options (X-Api-Key or x402 payment), cost per success call, rate limit (120/min), and the 402 retry workflow. It explicitly clarifies that billing is not a side effect, which is valuable context that complements the read-only and idempotent annotations without contradiction.

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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines) and is front-loaded. However, the purpose statement is repeated verbatim in the first sentence and the 'Purpose:' label, creating minor redundancy. Overall, each section earns 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—proxy to an arbitrary public API with auth, billing, rate limits, and caching—the description is remarkably complete. It covers endpoint flexibility, return format (raw API response), authentication methods, cost, rate limiting, caching, and error recovery. The presence of an output schema means return details need not be exhaustively described, but the description still sets proper expectations.

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% as all three parameters have descriptions, but the description adds practical usage semantics: it instructs to pass required parameters exactly, omit unknown fields, and specifically explains the __x_payment parameter's role when retrying after HTTP 402. This adds value beyond the schema's basic type/optionality notes.

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 explicitly states it is a proxy to the BloFin public API, enumerating the exact data types (tickers, instruments, orderbook, trades, candles) and the CORS-bypass purpose. This clearly distinguishes it from sibling market-data tools focused on other exchanges (e.g., coinglass_data, hyperliquid_data).

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 clear context for when to use this tool (for BloFin public market data) and includes practical guidelines such as 'Pass required parameters exactly; omit unknown fields' and how to handle 402 responses. However, it does not explicitly name alternative tools or provide exclusions, so it stops short of full guidance.

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

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

Annotations already declare destructiveHint=true, but the description goes beyond by specifying 'Behavior: DESTRUCTIVE... Can open/close positions.' It also details auth requirements ('X-Api-Key required'), cost ($0.01 USDC per call), rate limit (30/min), and tier. It clarifies that billing is not a side effect, and describes return values. This is rich behavioral context that significantly supplements the 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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags), but it starts with the core purpose and then repeats the identical phrase in the 'Purpose:' field, creating redundancy. This duplication makes it longer than necessary, though the structure helps navigation. It earns a 3 due to the unnecessary repetition.

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 destructive execution tool with payment requirements, the description is extremely complete. It covers behavior, auth, cost, rate limits, return values, and usage guidelines. It also clarifies billing as separate from side effects and warns against inventing fills. Given the tool's complexity and the presence of an output schema, this description provides all essential context for safe invocation.

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 schema has 100% description coverage for all 5 parameters, each with explanatory text. The description mentions flexible symbol formats which is also in the schema. However, the description adds no additional meaning beyond the schema—it does not elaborate on semantics of 'side', 'size', 'leverage', or payment parameters. Thus the baseline of 3 is appropriate since the schema does the heavy lifting.

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's function: 'Unified signal ingestion endpoint that normalizes symbols from any exchange format to executable format and routes to execution.' It explicitly mentions the ability to 'open/close positions', which distinguishes it from research-only sibling tools. The verb 'Call' plus resource 'cc.central_signal' is specific and unambiguous.

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 includes a 'Guidelines' section: 'Use for research / signal context. Pair with cc.agent_strategy (paper) before any live order. Do not invent fills from this data alone.' This provides explicit context and a caution, though it does not name alternative tools or explicitly state when not to use it. The pairing with paper trading suggests a workflow but falls short of a full when-to-use vs. alternatives comparison.

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

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

The description goes beyond the readOnlyHint annotation by explicitly stating 'READ-ONLY. Does not place orders, move funds, or mutate your exchange account.' It also discloses caching (~1800s), auth requirements, cost, rate limit, and the billing nature—all critical behavioral traits not present in annotations. No contradiction 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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Returns, Guidelines) and front-loaded with the core functionality. However, it is slightly redundant—'Detects and tracks CME Bitcoin futures gaps' appears both in the opening sentence and the Purpose section, and the 'Unique signal' phrase is repeated. Still mostly efficient.

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, the description covers all essential context: return format (array of gaps with direction, size, fill status, dates), auth mechanism, cost, rate limits, caching, and appropriate use cases. The output schema also exists, so the description does not need to over-explain return values. No critical gaps.

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% for the single optional parameter __x_payment, including its purpose and usage. The description adds only a brief mention of the parameter in the auth section, which restates rather than expands on the schema. Baseline 3 is appropriate since the schema carries the full load.

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 'Detects and tracks CME Bitcoin futures gaps (Friday close vs Monday open) with fill status monitoring.' This is a specific verb+resource statement that distinguishes it from sibling tools which focus on other market data. The 'Unique signal' tag reinforces its distinctiveness.

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 usage guidance: 'Use for research / signal context. Pair with cc.agent_strategy (paper) before any live order. Do not invent fills from this data alone.' This tells the agent when to use the tool and pairs it with an alternative/complement, exceeding basic clarity.

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

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

The description goes far beyond annotations: it explicitly states 'READ-ONLY. Does not place orders, move funds, or mutate your exchange account.' It adds caching behavior ('Responses may be cached (~2700s)'), auth requirements (X-Api-Key/x402), cost ($0.003 USDC), rate limit (30/min), and a note that linked Connect keys are free. This is exceptionally thorough and consistent with the readOnlyHint and idempotentHint 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 well-structured with labeled sections (Behavior, Auth, Cost, etc.), but it contains redundancy: the opening sentence repeats the 'Purpose:' phrase verbatim. It is longer than necessary for the value added, though the labeled structure helps scannability. The repetition of the exact same sentence is wasteful, so a medium score is appropriate.

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 (auth, cost, rate limits, caching, output type), the description covers every relevant aspect: what data is returned, how it behaves, how to authenticate, what it costs, rate limits, and usage guidance. Since an output schema exists, it does not need to detail return values, but it explains the output as 'normalized market microstructure data.' This is a complete context package 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?

The schema already documents both parameters with full coverage (100%), including the symbol default and the __x_payment retry use case. The description does not add additional parameter-level semantics beyond what the schema provides; it merely references the __x_payment in the auth section. Thus the baseline 3 applies as the description is not needed to compensate for missing schema info.

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' – a specific resource with explicit data types. This distinguishes it from narrower siblings like cc.funding_rates and cc.open_interest. The title 'Aggregated Derivatives Intelligence' reinforces its role as a comprehensive aggregate.

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 Guidelines section says 'Use for research / signal context' and recommends pairing with cc.agent_strategy before any live order, providing clear context. It also warns 'Do not invent fills from this data alone,' but it does not explicitly contrast with alternative sibling tools or state when to choose a more specialized tool. This is clear usage guidance but lacks explicit exclusions.

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

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

The description goes far beyond the readOnlyHint, detailing cache behavior (~300s), authentication methods (X-Api-Key or x402), cost per call, rate limits, and the HTTP 402 response for anonymous calls. This is rich behavioral context not available in 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 well-structured with labeled sections, but the first sentence is almost verbatim repeated in the 'Purpose:' section ('Fetches footprint/orderflow data showing buy vs sell volume imbalance at each price level. 5-minute cache.'). This duplication wastes space and reduces conciseness.

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?

Despite having an output schema, the description proactively covers return values, auth, cost, rate limits, and usage guardrails. It is thorough for a premium, pay-per-use data tool and leaves little ambiguity about selection and invocation.

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%: both 'symbol' and '__x_payment' already have descriptive text. The description itself adds no parameter-specific details beyond what the schema provides, so the baseline score of 3 is appropriate.

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 a specific verb ('Fetches'), resource ('footprint/orderflow data'), and scope ('buy vs sell volume imbalance at each price level'). While it doesn't explicitly name sibling alternatives, the specialized focus on orderflow footprint distinguishes it from broader tools like cc.coinglass_data.

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 clear usage context: 'Use for research / signal context' and 'Pair with cc.agent_strategy (paper) before any live order.' It also warns against over-interpretation ('Do not invent fills from this data alone'). No explicit exclusions of alternatives, but the guidance is useful.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: cost per call, rate limits, authentication methods, and the HTTP 402 response for anonymous calls. It also clarifies that billing is not a side effect, which goes beyond the 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 well-structured with labeled sections (Purpose, Behavior, Auth, etc.), but it contains redundancy: the opening sentence is nearly identical to the 'Purpose' field, and the 'Tags' section repeats indicator names. It is longer than necessary, though the structure helps navigability.

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 complexity (25+ indicators, auth, cost, rate limits, return values), the description is remarkably complete. It covers authentication, pricing, rate limiting, read-only behavior, return format, and integration guidance. The output schema is present, so return details are not required, but the description still summarizes outputs effectively.

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 schema already documents all parameters. The description adds value by enumerating example indicator values and mentioning that users can provide their own OHLCV data via the 'candles' parameter, but it does not deeply explain parameter interactions or formats beyond that.

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 a comprehensive technical analysis computation engine supporting 25+ indicators on OHLCV data. It distinguishes itself from sibling data tools by explicitly naming its function (compute indicators) and scope (any OHLCV data), making its 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?

It provides clear usage context: compute/parse/backtest only, no live orders, and explicitly suggests feeding outputs into cc.agent_strategy for paper trading. It does not enumerate alternatives directly, but the mention of the downstream sibling and the 'no live orders' exclusion gives practical guidance.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses caching (~3600s), authentication requirements (X-Api-Key or x402), HTTP 402 behavior for anonymous calls, cost per successful call, rate limits, and explicitly states 'READ-ONLY' with no side effects on exchange accounts. This is substantial behavioral context that annotations alone do not provide.

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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags), making it scannable. However, the Purpose section repeats the opening sentence nearly verbatim, and the cache duration is mentioned twice (60-min cache and ~3600s), adding minor redundancy. Still, every major section earns 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 has a simple schema, an output schema, and clear annotations, the description is comprehensive: it covers purpose, behavior, auth, cost, rate limit, return structure, and usage guidelines. An agent can confidently select and invoke this tool without needing additional undocumented context.

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 schema already covers the only parameter (__x_payment) with a detailed description, so baseline is 3. The tool description adds meaning by explaining the parameter's role in x402 payment proof, clarifying it is not a business parameter but a billing/payment mechanism, and tying it to auth and HTTP 402 handling. This goes beyond schema-only semantics.

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 opens with a specific verb 'Call' and clearly identifies the resource: 'Upcoming high-impact macroeconomic events (CPI, FOMC, NFP, etc.) with forecast vs previous values.' It also names concrete examples and contrasts with other data sources via tags, clearly distinguishing it from sibling tools like market news or funding rates.

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 'Guidelines' section explicitly states when to use the tool ('Use for research / signal context') and when not to rely on it alone ('Do not invent fills from this data alone'). It also names a specific sibling, cc.agent_strategy, as the recommended paper-trading companion before live orders, providing clear alternative usage.

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

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

The description discloses behavior beyond annotations: states READ-ONLY, does not place orders/move funds, mentions caching (~3600s), email auth methods, HTTP 402 for anonymous calls, cost per call, and rate limit. This is rich context that annotations do not cover, and it is consistent with readOnlyHint and idempotentHint.

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 contains redundancy: the opening sentence and the 'Purpose' section repeat nearly identical content. While structured with labels, the extra tags and duplicated purpose reduce conciseness.

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 is exceptionally complete: covers purpose, behavior, auth, cost, rate limits, return format, and usage guidelines. With an existing output schema and no required parameters, the description fully compensates for any missing context and provides operational details.

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% for the only parameter (__x_payment), so baseline is 3. The description adds context by explaining that __x_payment is an alternative to X-Api-Key auth and how to use it after an HTTP 402, going beyond the schema's description.

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's function: real-time Bitcoin/crypto ETF inflow and outflow data tracking institutional positioning, naming specific ETFs (GBTC, IBIT, FBTC). This is a specific verb+resource pair that distinguishes it from sibling data tools like funding rates or open interest.

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 usage guidance: use for research/signal context and pair with cc.agent_strategy (paper) before any live order. It also warns not to invent fills from this data alone, clearly delineating when to use this tool vs alternatives.

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

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

Annotations mark destructiveHint=true and readOnlyHint=false, and the description elaborates by stating 'Behavior: DESTRUCTIVE. Normalizes the signal and routes toward trade execution... Can open/close positions.' It also adds auth requirements, cost, and rate limits, enriching the behavioral profile beyond what annotations alone 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 description is well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines), but the opening sentence redundantly repeats the Purpose section almost verbatim. This minor inefficiency prevents a perfect score.

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?

Covers all critical operational aspects—purpose, behavior, auth, cost, rate limiting, return semantics, and usage guidance. The presence of an output schema reduces the need for return-value detail, and the description provides a high-level summary of the proxied response.

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 description need not restate parameter details. It does not provide additional per-parameter context, but the schema already documents each field with basic descriptions, hence a baseline of 3 is appropriate.

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 identifies the tool as a public-facing webhook endpoint for TradingView alerts and external signal providers, with the specific action of normalizing and forwarding to execution. This distinct verb+resource framing differentiates it from siblings like cc.central_signal or cc.trade_builder.

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 guidelines: 'Use for research / signal context. Pair with cc.agent_strategy (paper) before any live order. Do not invent fills from this data alone.' This names an alternative tool for paper trading and warns against using the signal alone for fills, covering both when and when-not to use.

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

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

The description significantly expands on the annotations by detailing that the operation is READ-ONLY, never places orders or moves funds, and includes caching (~1800s), authentication methods (X-Api-Key or x402), HTTP 402 behavior, cost ($0.0005 USDC), rate limits (120/min), and clarifies that billing is not a side effect. This adds substantial context beyond the inherent readOnlyHint and idempotentHint flags.

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 well-structured with clear labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags), but it contains a verbatim duplication of the opening sentence under 'Purpose,' which wastes space. The length is justified by the richness of information, but the redundancy prevents a higher score.

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 (auth, payment, caching, rate limits) and the existence of an output schema, the description covers all necessary operational aspects: return values (current index plus 7/30/90 day history), usage context, safety profile, and cost/payment details. This is fully sufficient for an agent to invoke the tool correctly.

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 schema already fully describes the single optional __x_payment parameter (100% coverage), including its purpose and when to use it. The description does not add additional parameter-level detail; it only references the payment proof in the auth context. Therefore, the description adds no meaningful value beyond the schema.

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 'Crypto market Fear & Greed composite index (0-100) with historical values and trend direction' using a specific verb and resource. It also distinguishes the tool from siblings by highlighting its unique sentiment index and historical/trend data, which is not implied by the title alone.

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?

Explicit guidelines state 'Use for research / signal context' and recommend pairing with cc.agent_strategy before live orders. It also warns against using the data alone to invent fills, effectively providing both inclusion and exclusion criteria.

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

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

The description goes far beyond the annotations by disclosing read-only nature ('Does not place orders, move funds, or mutate your exchange account'), caching ('~1800s'), authentication methods (X-Api-Key or x402 payment proof), rate limits ('60/min'), and billing details ($0.001 USDC per successful call). No contradictions with annotations are present.

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 front-loaded with the core purpose but is overly verbose and repetitive. The exact phrase 'Current and predicted perpetual futures funding rates across all major exchanges via Coinglass with 30-min cache' appears twice (first sentence and the 'Purpose:' line). While the detailed sections (Auth, Cost, Rate limit, Guidelines) are useful, redundancy and length make it less concise than ideal.

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 is highly complete for the tool's complexity: it covers purpose, behavior, auth, cost, rate limits, return summary, and usage guidelines. Given that an output schema exists, the description need not detail return values further. The only minor gap is the absence of explicit 'when not to use' beyond the fill caution, but overall it is sufficient for selecting and invoking 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?

The input schema already provides 100% coverage of the two parameters with clear descriptions. The description adds minimal extra meaning, only confirming that __x_payment is 'not a business parameter' and that symbol defaults to 'all major'. Since schema coverage is complete, the baseline of 3 is appropriate; the description does not significantly enhance parameter understanding.

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's purpose: 'Current and predicted perpetual futures funding rates across all major exchanges via Coinglass with 30-min cache.' It specifies a distinct resource (funding rates), the data source (Coinglass), and scope (all major exchanges), making it unambiguous and distinguishable from sibling tools.

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 'Guidelines' section explicitly tells when to use it ('Use for research / signal context'), recommends pairing with cc.agent_strategy before live orders, and warns not to invent fills from this data alone. This provides clear usage context, an alternative tool reference, and an explicit exclusion, satisfying the criteria for explicit when/when-not.

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

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

The description discloses READ-ONLY behavior, no order placement or fund movement, response caching (~1800s), authentication methods (X-Api-Key or x402), HTTP 402 behavior for anonymous calls, cost per call, rate limits, and explicitly states billing is not a side effect. This goes far beyond the annotations, which already indicate read-only and idempotent.

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 logically organized with labeled sections, but the opening sentence and the 'Purpose' section repeat the exact same content ('Whale positions and activity alerts... 30-min cache'), adding redundancy without new information. It's detailed and mostly earns its length, but the duplication is a clear flaw.

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?

Covers purpose, behavior, auth, cost, rate limit, return values, and usage guidelines, making it a fully self-contained reference. The output schema further handles return details, so the description complements it well and equips an agent to invoke the tool correctly.

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 schema has 100% coverage for the single optional __x_payment parameter, explaining it as an x402 payment proof for retrying after HTTP 402. The tool description adds context about anonymous calls receiving HTTP 402 and the auth flow, complementing the schema's explanation and giving a slight score boost over baseline.

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 'Whale positions and activity alerts from Hyperliquid DEX showing large trader positioning,' which is specific to Hyperliquid whale data and distinguishes it from siblings like cc.coinglass_data. It also mentions the 30-min cache, adding further specificity.

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 'Guidelines' section explicitly advises use for research/signal context, names cc.agent_strategy as a companion for paper trading before live orders, and warns against inventing fills from this data alone. This provides clear when-to-use and complementary guidance.

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

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

Beyond annotations, the description discloses that the tool is READ-ONLY with respect to the exchange account, and details auth requirements, cost, rate limits, and HTTP 402 handling. It clearly distinguishes billing from side effects, adding significant context.

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 front-loaded with the core purpose, but it repeats the actions list twice, making it redundant. The inclusion of tags and repetitive phrases means some sentences do not earn their 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?

The tool is complex with multiple actions and an output schema, but the description covers auth, rate limits, cost, return types, and error handling. It lacks explicit per-action parameter mappings, but the schema and action names make it inferable.

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 input schema already provides descriptions for all 8 parameters, so the baseline is 3. The description adds minimal extra semantic detail, only vaguely referencing 'prompt→code' and generic guidance like 'Pass required parameters exactly'.

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 that this is an 'AI-powered indicator workshop' and enumerates specific actions (generate, list_library, get_indicator, delete_indicator, get_draft, save). It distinguishes itself from sibling tools by focusing on custom indicator generation rather than market data or strategy execution.

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 clear context for when to use the tool and lists distinct actions for various use cases. However, it does not explicitly mention alternatives or exclusion criteria, so the 'when not to use' guidance is missing.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds rich behavior: 'READ-ONLY. Does not place orders, move funds, or mutate your exchange account. Responses may be cached (~1800s).' It also discloses auth methods, cost, rate limit, and return format, providing a complete behavioral picture with no contradiction.

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?

Despite length, the description is well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags). The first sentence is front-loaded with purpose, and each section earns its place by conveying essential operational details without fluff.

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?

This tool has complex context—payment proofs, caching, rate limits, output schema—and the description covers all of it: auth requirements, cost, caching, rate limit, return structure, and safe usage guidance. The output schema exists, so extra return detail is bonus, making the description complete for safe and correct invocation.

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 each parameter already described (symbol, range, __x_payment). The description does not add further parameter-specific semantics beyond saying the return is a 3D matrix, which relates to output. Per rubric baseline, 3 is appropriate when the schema does the heavy lifting.

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 opens with a specific verb+resource: 'Call cc.liquidation_heatmap — Liquidation cluster visualization data showing where leveraged positions would be force-closed at each price level.' This clearly states what the tool does and distinguishes it from siblings like cc.liquidation_max_pain by focusing on cluster visualization and magnetic price targets.

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 context: 'Use for research / signal context. Pair with cc.agent_strategy (paper) before any live order. Do not invent fills from this data alone.' This tells when to use it, how to combine it with a sibling tool, and warns against misusing it for fill data. It also explains auth and cost prerequisites.

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

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

Beyond the readOnlyHint annotation, the description discloses caching (~1800s), authentication requirements (X-Api-Key or x402), cost ($0.003 USDC), rate limits (30/min), and notes that billing is not a side effect. This adds substantial behavioral context that the annotations alone do not capture. No contradictions.

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 well-structured with clear sections (Behavior, Auth, Cost, Returns, Guidelines) but contains redundancy: the opening line and 'Purpose' field are identical, repeating the same sentence. This wastes space and could be trimmed. It is front-loaded with the purpose but the duplication prevents a higher score.

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 (auth, cost, caching, rate limits), the description is thorough. It covers return fields, pairing guidance, safety precautions, and billing semantics. An output schema exists, but the description still explains the return structure and usage context, making it complete for an agent to select and 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% for both parameters. The description adds context for '__x_payment' by explaining it as an x402 payment proof and how it relates to the X-PAYMENT header, reinforcing the schema meaning. It also clarifies the required 'symbol' parameter implicitly by describing per-symbol return data. Useful but not essential beyond the schema.

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 identifies exact price levels for maximum liquidation cascades for longs and shorts. This is a specific verb-resource pairing and distinguishes it from the sibling 'cc.liquidation_heatmap' by focusing on max-pain levels. The 'Purpose' line reinforces the primary function without ambiguity.

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 usage context: 'Use for research / signal context' and 'Pair with cc.agent_strategy (paper) before any live order.' It also warns against inventing fills from this data alone. While it doesn't explicitly exclude other tools, it names an alternative and gives clear when-to-use guidance, satisfying the criteria.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description goes further by stating it is READ-ONLY, does not place orders or charge per-endpoint fees by itself, is free to list, and notes that individual endpoint calls are billed separately. It also mentions rate limits and the JSON envelope structure, providing behavioral context beyond the 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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines). Every sentence adds functional value; no fluff or repetition. It is appropriately detailed for a discovery tool that agents are expected to call first.

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 parameters, an output schema, and rich annotations, the description still adds critical operational details: authentication optionality, cost model, rate limit, return envelope, usage order, and exclusion of admin-only tools. This makes the tool fully self-contained and easy to invoke correctly.

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 has zero parameters and the schema is fully self-explanatory, so the baseline is 4. The description adds context about what is returned (endpoint names, prices, parameters, tiers) but does not need to explain parameter semantics since there are none.

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 lists Central Command x402 catalog endpoints (names, prices, parameters, tiers) and frames its purpose as discovering which cc.* tools exist before calling them. This distinguishes it from sibling execution tools like cc.trade_builder or cc.asset_scanner, which actually perform actions.

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?

Explicit guidance is given: 'Call this first. Then invoke cc.<slug> with required params.' It also notes that admin-only tools are omitted, setting clear expectations about what will or won't be listed. This is actionable and contrasts with running a specific endpoint.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses caching behavior, authentication requirements (HTTP 402 with payment proof), cost, rate limits, and explicitly states it does not place orders or mutate accounts. This is rich behavioral transparency that adds significant value beyond the structured 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 well-structured with labeled sections, but it redundantly repeats the purpose sentence twice (first sentence and 'Purpose' line). This wastes space and could be tightened. Other details earn their place, but the repetition hurts conciseness.

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?

Covers all relevant aspects: purpose, behavior, auth, cost, rate limits, return format, usage guidelines, and safety warnings. Despite the redundancy, it is exceptionally complete for a data-fetching tool, leaving few unanswered questions.

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 both symbol and __x_payment documented. The description adds context around __x_payment in the auth section but doesn't add additional parameter semantics beyond the schema. Baseline 3 applies since the schema already handles parameter documentation.

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 the global long vs short account positioning ratio from Coinglass, with specific data points (long_percent, short_percent, ratio) and context (retail sentiment, 60-min cache). It distinguishes from siblings by emphasizing sentiment/positioning and the contrarian tag, making its purpose specific and unambiguous.

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 usage guidance: 'Use for research / signal context' and cautions against inventing fills, recommending pairing with cc.agent_strategy before live orders. However, it doesn't explicitly contrast with alternative sentiment tools, so it lacks a full when-not-to-use comparison.

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

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

The description discloses read-only behavior, caching (~1800s), auth requirements (X-Api-Key or x402 proof), cost per call, rate limit (60/min), and that payment is billing not a side effect. This goes well beyond the readOnlyHint annotation by adding operational context.

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 well-structured with clear sections, but it duplicates the opening sentence in the 'Purpose' line ('Multi-period moving average values...' appears twice). This repetition and the inclusion of tags/tier make it slightly verbose, though still readable.

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 key operational aspects: behavior, auth, cost, rate limit, return summary, and usage guidelines. With an output schema present, it doesn't need to explain return values in detail, making it fully adequate for an agent to select and 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?

The input schema covers all parameters (100% coverage), but descriptions are minimal. The tool description adds general context about the data returned but does not specify symbol format or examples, so it provides limited added value beyond the schema baseline.

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 'Multi-period moving average values (SMA/EMA at various lengths) via Coinglass' and specifies the exact periods returned (7, 25, 50, 99, 200), making the tool's function unambiguous and distinguishing it from sibling data tools like funding rates or open interest.

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.' It also cautions against 'inventing fills' from this data alone, clearly defining when to use 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.

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

Beyond annotations (readOnly, destructiveHint:false), the description discloses caching ('Responses may be cached (~1800s)'), authentication requirements ('X-Api-Key or x402 payment proof'), cost ('$0.002 USDC per successful call'), rate limits ('30/min'), and clarifies that billing is not a side effect. This is rich, useful context that exceeds the annotation baseline.

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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate Limit, Returns, Guidelines) and every sentence offers value. However, the purpose is stated twice ('Call cc.market_news — Aggregated...' and 'Purpose: Aggregated...'), which is redundant. Slightly long but still efficient.

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 and the presence of an output schema, the description covers all necessary aspects: return values, auth, cost, rate limits, usage guidance, and exclusions. It leaves no critical gap for an agent to successfully select and 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?

The schema already provides 100% coverage of the two parameters, including descriptions like 'Filter: btc, eth, sol, macro, all Optional' for category and the retry purpose for __x_payment. The description adds no new parameter-specific semantics beyond restating that returned articles are categorized. Baseline 3 is appropriate.

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's function: 'Aggregated crypto and macro market news from multiple sources with relevance scoring and categorization.' It uses a specific verb+resource (call cc.market_news) and differentiates from siblings by mentioning categories, relevance, and pairing with cc.agent_strategy.

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 when-to-use guidance: 'Use for research / signal context' and 'Pair with cc.agent_strategy (paper) before any live order.' It also warns against improper use: 'Do not invent fills from this data alone.' This fully covers usage context and alternatives.

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

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

Beyond the annotations (destructiveHint=true), the description discloses specific behaviors: CAN place/cancel orders, treat as potentially destructive, confirm intent before live trading. It also details auth requirements, billing model, rate limits, and error-reporting expectations. This provides rich context that annotations alone do not capture.

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 organized into labeled sections (Purpose, Behavior, Auth, Cost, etc.), which aids readability. However, the opening sentence repeats the purpose, and the 'Purpose' section duplicates it verbatim, adding unnecessary length. The structure is good but the redundancy hurts conciseness.

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?

Covers return format, auth, cost, rate limit, safety, and behavioral guidelines. With an output schema present, the description provides comprehensive context for an autonomous trading tool, leaving no major gaps.

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 input schema has 100% parameter descriptions, so the schema already covers semantics. The description adds no further param-level detail. Baseline of 3 is appropriate since the schema does the heavy lifting and the description does not need to compensate.

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 autonomous AI agent for strategy development, backtesting, and market monitoring, with conversational interaction. It distinguishes itself from data-only tools by explicitly noting it can place/cancel orders. However, the purpose is stated twice (once in the opening sentence and again under 'Purpose'), which is redundant and slightly undermines clarity.

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 guidelines to prefer paper/simulation paths and require human confirmation for live trading, which is strong actionable guidance. It also notes rate limits and cost, indicating operational usage constraints. It does not explicitly contrast with sibling tools like cc.strategy_backtest, but the safety directives and 'conversational AI' framing imply when this tool is appropriate.

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

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

The description goes well beyond annotations by disclosing read-only behavior, response caching (~1800s), authentication requirements (X-Api-Key or x402 payment), costs, rate limits, and HTTP 402 behavior for unauthenticated calls. It also clarifies that billing is not a side effect. These details give the agent essential operational context without contradicting the 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 well-structured with labeled sections (Behavior, Auth, Cost, Returns, Guidelines), but it repeats the opening sentence verbatim in the 'Purpose:' section and includes a tags list that adds marginal value. It is more verbose than necessary, though each section is scannable.

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 purpose, behavior, auth, cost, rate limits, return summary, and usage workflow, making it highly complete for a tool that also has annotations and an output schema. It could mention potential error cases or asset classes, but the provided information is already substantial.

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 input schema already provides descriptions for all three parameters with 100% coverage, so the description adds little semantic detail beyond the schema. It mentions the __x_payment parameter in context of authentication but does not offer additional constraints or usage syntax.

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 historical and current aggregated open interest across major exchanges, with a 30-min cache. It specifies the return content (time-series data plus per-exchange breakdown) and distinguishes itself from sibling tools focused on other data types like funding rates or liquidations.

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 includes explicit usage guidelines: use for research/signal context, pair with cc.agent_strategy for paper trading before live orders, and warns against inventing fills from this data. This provides both when-to-use and when-not-to-use guidance, and names a complementary sibling tool.

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

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

Annotations only mark it as read-only, idempotent, and non-destructive. The description adds rich behavioral context: READ-ONLY, no order placement or fund movement, auth requirements (X-Api-Key or x402 payment), cost per call, rate limit, and clarification that billing is not a side effect. It also notes the possibility of forwarding raw signed txs, which is a subtle exception to read-only behavior. This goes well 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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, Rate, Returns, Guidelines, Tags), but it contains an obvious redundancy: the opening sentence 'Multi-endpoint Solana RPC proxy with automatic failover (Alchemy, public, Ankr) for any JSON-RPC method. Reliable Solana access.' is repeated verbatim in the Purpose section. This wastes tokens and slightly hampers conciseness.

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 necessary aspects for a generic RPC proxy: purpose, behavior, auth, cost, rate limit, return type, and usage guidelines. It also includes a safety note about raw signed transactions. Given that an output schema exists, it doesn't need to detail return structures. The description stands alone as a complete guide for selection and invocation.

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 schema already has 100% parameter descriptions, so the baseline is 3. The description enhances param understanding by explaining that method is any JSON-RPC method, that params is the RPC parameter array, and by linking __x_payment to the x402 payment proof mechanism for retrying after HTTP 402. This adds useful context beyond the schema's minimal descriptions.

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 it is a 'Multi-endpoint Solana RPC proxy with automatic failover (Alchemy, public, Ankr) for any JSON-RPC method.' This specific verb+resource+scope distinguishes it from sibling tools like cc.coinglass_data or cc.hyperliquid_data, which focus on specific data endpoints rather than a generic RPC proxy.

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 usage context: 'Forward JSON-RPC only. Prefer eth_call / read methods. Sending raw signed txs is possible if you pass them — that is your responsibility.' It also details auth, cost, and rate limits that guide when to use the tool. However, it does not explicitly mention alternatives or when NOT to use this tool, so it falls short of a 5.

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

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

The description goes far beyond the annotations by explicitly stating 'Behavior: READ-ONLY. Does not place orders, move funds, or mutate your exchange account', and also discloses auth methods (X-Api-Key or x402), cost per call, rate limits, and retry behavior on 402. This provides rich behavioral context that annotations alone do not cover, and it is consistent with the readOnlyHint=true annotation.

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 contains significant redundancy. The 'Purpose:' section repeats the opening sentence verbatim, and the 'Tags:' section adds little new information. While the labeled sections (Behavior, Auth, Cost, Rate limit, Returns, Guidelines) improve structure, the duplication and extra length reduce conciseness.

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 complex tool with auth, payment, and rate-limiting considerations, the description is exceptionally complete. It covers operational requirements (X-Api-Key / x402), cost per call, rate limits, return format, and specific error-handling instructions ('On 402, settle payment then retry with X-PAYMENT'). Combined with a rich output schema and thorough annotations, nothing essential is missing.

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 input schema already covers all six parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal semantic value for parameters beyond noting that the message can request 60+ data actions and clarifying that __x_payment is 'not a business parameter', but these nuances exist in the schema as well. It does not compensate further for parameter usage.

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 identifies the tool as a 'Full AI trading assistant' with real-time market data, position analysis, chart drawing commands, and multi-tool execution, and lists 60+ data actions. However, it does not explicitly distinguish itself from sibling chat tools like cc.squirrel_chat_v2 or cc.openclaw_chat, missing an opportunity for differentiation.

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 no explicit guidance on when to use this tool versus alternatives. It lists supported capabilities and gives operational guidelines for parameters and 402 retries, but does not state when to choose this over dedicated data tools (e.g., cc.funding_rates) or other chat tools. Usage is only implied through the feature list, not explicitly stated.

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

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

The description goes well beyond the annotations (destructiveHint=true) by detailing that it can place/cancel orders and manage positions, requiring confirmation before live trading. It also discloses auth requirements, cost, rate limits, and a directive to report real HTTP errors, adding rich behavioral context.

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 well-structured with labeled sections (Purpose, Behavior, Auth, Cost, etc.) but contains redundancy: the full capability list is repeated verbatim in both the opening sentence and Purpose section. It is informative but not maximally concise.

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?

This is a complex, potentially destructive tool, and the description covers all essential aspects: purpose, behavior, auth, cost, rate limits, return type, and safety guidelines. With output schema present and detailed annotations, the description is thorough enough for safe and correct invocation.

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% for all three parameters, so the schema already fully documents them. The description does not add parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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 a full AI trading assistant that can analyze markets, compute indicators, fetch live data, place orders, and manage positions. This specific verb+resource framing distinguishes it from sibling data tools and makes its 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?

The description provides clear context for when to use the tool (as a conversational trading agent) and includes explicit safety guidelines like preferring paper/simulation and requiring human confirmation for live money. It does not explicitly name alternative tools or when-not-to-use scenarios, but the context is strong.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses live near-real-time data, auth via X-Api-Key/x402 payment, HTTP 402 for anonymous calls, cost per successful call, billing clarification, and rate limit of 5/min. It also describes the return payload, adding substantial behavioral context.

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 well-structured with labels (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags), but the first sentence and the 'Purpose' section repeat the exact same phrase verbatim, which is redundant. Front-loaded with call instruction, but the duplication prevents a 5.

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 premium, complex tool with 5 parameters and an output schema, the description provides purpose, behavior, auth requirements, cost, rate limits, return summary, and usage guidelines. It is sufficiently complete for an agent to select and invoke correctly.

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%, so baseline is 3. The description does not add per-parameter syntax or format details beyond the schema; parameters like strategy, symbol, days, and timeframe are already described in the input schema. No compensation needed.

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 a specific verb+resource: takes a natural language strategy, generates and runs executable code against historical OHLCV data with TP/SL/trailing stop simulation. It differentiates from siblings by emphasizing 'backtest only — no live orders' and referring to cc.agent_strategy for paper trading.

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 includes an explicit 'Guidelines' section: 'Compute / parse / backtest only — no live orders. Feed outputs into cc.agent_strategy with force_paper=true to paper-trade.' This provides direct when-to-use and alternative direction. It also specifies auth, cost, and rate limits as operational constraints.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds rich behavioral context: 'READ-ONLY. Does not place orders, move funds, or mutate your exchange account,' plus auth methods (X-Api-Key/x402), billing details, and rate limits. This fully discloses operational characteristics.

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 well-organized with clear labels (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags) and every section provides useful operational details. However, the Purpose section redundantly repeats the opening sentence almost verbatim, which slightly reduces conciseness.

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 necessary context for a pay-per-use API tool: behavior, auth, cost, rate limits, return format, and usage guidance. It even names an alternative sibling tool for paper trading. With an output schema present, the return-value overview is sufficient and complete.

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 both parameters fully described in the schema. The description adds minimal input-specific guidance beyond the schema, though it does clarify the output categories (timeframes, indicators, etc.) that the description parameter should yield. Baseline 3 is appropriate as the schema handles the parameter semantics.

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 states a specific verb+resource: 'Parses natural language strategy descriptions into structured executable specifications.' It clearly differentiates from siblings like cc.agent_strategy (execution) and cc.strategy_backtest (backtesting) by focusing on parsing/structuring, and even references feeding outputs into cc.agent_strategy for paper trading.

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 usage guidance: 'Guidelines: Compute / parse / backtest only — no live orders. Feed outputs into cc.agent_strategy with force_paper=true to paper-trade.' This tells when to use (for parsing strategies) and when not (no live orders), and names an alternative tool for paper trading.

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

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

The description discloses behavioral traits beyond annotations: it clarifies that it is 'mostly READ (plan/validate)' and 'WRITE/destructive only when action=execute,' which aligns with the annotations but adds essential nuance about when destructive behavior occurs. It also details authentication methods, billing, cost, and rate limits, providing comprehensive behavioral transparency.

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 structured with labeled sections (Purpose, Behavior, Auth, Cost, etc.) and front-loaded with the core purpose. However, it is repetitive: the purpose statement is essentially duplicated at the beginning and again under 'Purpose.' This redundancy prevents a perfect score.

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 (auth, billing, rate limits, destructive potential, execution risks), the description covers all relevant context: what it returns, when to use plan vs execute, cost implications, authentication methods, and rate limits. The presence of an output schema reduces the need to explain return values, but it does so anyway, making it highly complete.

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 input schema already provides full descriptions for all three parameters (idea, risk_pct, __x_payment), achieving 100% schema description coverage. The tool description adds minimal parameter-specific semantics, only mentioning 'action=execute' and 'confirm_live' as potential extra parameters not in the schema, but does not enhance the understanding of the existing parameters beyond the schema.

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's purpose with a specific verb and resource: 'Takes natural language or structured trade ideas, fetches live market context, and generates fully executable order parameters with AI reasoning.' This distinguishes it from sibling tools like cc.asset_scanner or cc.twap_executor, which are data fetchers or execution tools without the AI planning aspect.

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 clear context on when to use the tool (for trade idea generation) and gives explicit directives like 'Prefer action=plan first' and 'For live money require explicit human confirmation (confirm_live / action=execute).' However, it does not explicitly name alternative tools for similar tasks, only implying them through the context of siblings.

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

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

The description adds substantial behavioral context beyond the annotations: it explicitly states READ-ONLY, does not mutate account, notes caching (~900s), details auth methods (X-Api-Key, x402), rate limits, billing cost, and that billing is not a side effect. This fully discloses behavior and operational constraints.

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 well-structured with clear labeled sections (Behavior, Auth, Cost, Rate limit, Returns, Guidelines). However, it repeats the same purpose sentence twice ('Call cc.traditional_markets — Live quotes...' and 'Purpose: Live quotes...'), which is redundant. Otherwise, the formatting is excellent and front-loaded.

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 simplicity (no required params, simple data fetch), the description is exceptionally complete. It covers usage, auth, cost, rate limits, return content, and integration with other tools. An output schema exists, so return structure is further documented. No critical gaps.

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 input schema already describes the single optional parameter __x_payment with high clarity. The description additionally explains its context in the auth flow (x402 payment proof, retry after HTTP 402), reinforcing its purpose beyond the schema. Since schema coverage is 100%, this extra context earns a 4.

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 explicitly states the tool provides live quotes for a specific set of traditional market instruments (S&P 500, Nasdaq, Dow, VIX, etc.). This is a specific verb+resource+scope that clearly distinguishes it from sibling tools focused on crypto or other data. No ambiguity.

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 'Guidelines' section explicitly states when to use it ('research / signal context'), recommends pairing with cc.agent_strategy (paper) before live orders, and warns not to invent fills from this data alone. This provides clear when/when-not guidance and names an alternative/complementary tool.

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

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

The description goes far beyond the annotations by detailing 'DESTRUCTIVE. Splits and submits real exchange orders over time. Irreversible fills once slices execute. Not a simulation.' It also discloses auth requirements (X-Api-Key, linked exchange credentials), cost ($0.015 USDC per call), rate limit (10/min), and explicitly distinguishes billing from side effects. This is comprehensive behavioral disclosure.

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 well-sectioned and front-loaded, but it repeats the purpose twice (first sentence and the 'Purpose:' line). This redundancy adds bulk without new information. The remaining content is valuable, but the duplication prevents a higher score.

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 destructive execution tool with an output schema, the description covers all necessary context: auth, cost, rate limit, return values, safety guidelines, and human-confirmation requirements. It leaves no major gaps for an 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?

Although schema coverage is 100%, the schema descriptions are generic ('Parameter `side` (string). Required.'). The tool description adds meaningful context by explaining the mechanism ('splits large orders into smaller randomized slices over configurable time windows'), implicitly clarifying total_size, slices, and duration_minutes. It also describes expected outputs (filled slices, average fill price, remaining quantity).

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's function: 'Time-Weighted Average Price execution engine — splits large orders into smaller randomized slices over configurable time windows to minimize market impact.' It uses a specific verb ('splits') and resource ('large orders'), and explicitly contrasts with simulation ('Not a simulation'), distinguishing it from sibling analysis/backtest tools.

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?

It provides explicit guidance: 'Prefer paper/simulation paths. For live money require explicit human confirmation (confirm_live / action=execute).' This tells the agent when to use the tool and when to exercise caution, though it does not name specific alternative tools. The context is clear enough for appropriate selection.

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

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

Behavioral transparency is exceptional: it explicitly says 'READ-ONLY. Does not place orders, move funds, or mutate your exchange account,' plus discloses authentication methods, cost ($0.001 USDC), rate limit (120/min), and the raw-tx responsibility caveat. This goes far beyond the annotations (readOnlyHint, idempotentHint) by adding operational and safety context.

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 well-organized with labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines, Tags) and front-loads the core function. However, it repeats the exact purpose sentence in the 'Purpose:' field, creating redundancy. Still, every other sentence earns 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?

For a multi-chain RPC proxy with an output schema, the description is remarkably complete: it covers the exact chains, the request format, return type ('Standard EVM JSON-RPC response'), auth, cost, rate limits, and safety behavior. No critical context is missing for an agent to decide whether and how to invoke this 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%, so the baseline is 3. The description adds value beyond the schema by advising 'Prefer eth_call / read methods' and warning about raw signed transactions, which gives the agent extra guidance on how to construct params not present in the schema's bare field descriptions.

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 states a specific verb ('forward') and resource ('Multi-chain EVM RPC') with explicit chain scope: 'Ethereum, Base, Arbitrum, Optimism, Polygon, and BSC.' It also uses 'Gateway' in the title and 'forwarder' in the description, clearly distinguishing it from sibling tools like cc.solana_rpc or data-fetching tools.

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 clear usage context: 'Forward JSON-RPC only. Prefer eth_call / read methods' and 'Sending raw signed txs is possible if you pass them — that is your responsibility.' It does not explicitly name alternatives or exclusions, but the EVM-specific chain list inherently separates it from Solana RPC sibling, and the read-only preference is stated.

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