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?

Goes well beyond the readOnly/idempotent annotations by disclosing auth modes (X-Api-Key or x402), the HTTP 402 anonymous path, per-call cost ($0.008 USDC, free for linked Connect keys), a 15/min rate limit, ~300s caching, and an explicit 'this is billing, not a side effect' clarification. This is exactly the extra context annotations cannot carry.

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?

Front-loaded and section-labeled (Purpose, Behavior, Auth, Cost, Rate limit, Returns, Guidelines), which helps scanning, but the purpose sentence is duplicated verbatim and the trailing Tags line restates already-listed keywords. Real redundancy dilutes an otherwise well-organized block.

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 behavior, auth, billing, rate limits and downstream workflow, and since an output schema exists it need not detail return values. Only gap is any concrete guidance on the business parameters (e.g., symbol format/timeframe options).

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 nominally 100%, so the baseline is 3, but those descriptions are tautological ('Parameter `symbol` (string). Required.') and the description adds no syntax, format, or validation meaning for symbol/timeframe beyond implying BloFin data. Marginal value over 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?

States a specific verb and resource — fetching market context (BloFin OHLCV candles, Central Command indicators, open interest, news) — and its 'all-in-one' framing implicitly distinguishes it from single-purpose siblings like cc.market_news and cc.open_interest. An agent can tell what it returns without opening the schema.

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 downstream guidance ('Compute / parse / backtest only — no live orders', feed into cc.agent_strategy with force_paper=true), but never states when to prefer this tool over its narrower siblings. Usage is implied rather than contrasted.

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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: ~1800s caching, X-Api-Key or x402 payment auth, HTTP 402 behavior for anonymous calls, $0.002 USDC cost, 30/min rate limit, and premium tier. This is exactly the behavioral detail annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-labeled sections (Behavior, Auth, Cost, Rate limit, Returns, Guidelines) aid scanning, but the opening sentence and the 'Purpose:' line are a wasteful verbatim duplication, and the Tags/tier metadata is filler. Front-loaded but not tight.

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?

An output schema exists, so return values need no prose, and the description covers auth, cost, rate limits, caching, and usage cautions. Nothing an agent needs to invoke this correctly 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?

One parameter with 100% schema description coverage, so the schema already documents __x_payment fully. The description reinforces the auth header mechanism (X-PAYMENT / __x_payment) but adds no format or syntax beyond the schema. 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?

States a specific resource and computation: CME Bitcoin futures weekend gaps (Friday close vs Monday open) with fill status from BloFin candles. An agent can distinguish it from generic market-data siblings. However, the opening sentence and the 'Purpose:' line are verbatim duplicates, and sibling differentiation is limited to a pairing mention.

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: 'Use for research / signal context,' 'Pair with cc.agent_strategy (paper) before any live order,' and 'Do not invent fills from this data alone.' It names a sibling and a caution, though it does not spell out when NOT to use it versus other signal tools.

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, and the description adds substantially beyond them: ~2700s response caching, auth mechanisms (X-Api-Key or x402 payment proof), HTTP 402 behavior for anonymous calls, $0.003 USDC per-call cost, and a 30/min rate limit. The billing clarification ('This is billing, not a side effect') is exactly the kind of context an agent needs before calling a paid endpoint.

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 first sentence of the description is repeated verbatim in the 'Purpose:' paragraph ('BloFin derivatives data: BloFin open interest and funding, and a bulk scan of BloFin tickers and funding. Paid calls carry BloFin and public-domain (CFTC) data only.' appears twice). This redundant duplication wastes a substantial fraction of the text, even though the auth/cost/rate-limit block is genuinely informative.

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?

An output schema exists, so return values need not be explained here, and the description still summarizes them ('Normalized market microstructure data'). Combined with full parameter coverage, complete annotations, and explicit auth/cost/rate-limit/guideline notes, an agent has everything required to invoke this 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% and both parameters (symbol, __x_payment) are documented in the schema, so the description adds no syntax or format detail for symbol beyond 'default: top 20' which the schema already states. Per the rubric, a high-coverage schema sets the baseline at 3.

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?

Names a specific verb (call/retrieve) and a concrete resource: BloFin open interest, funding, and a bulk scan of BloFin tickers. An agent can distinguish it from siblings like cc.open_interest or cc.funding_rates, though the description never explicitly contrasts with them. The opening line and the 'Purpose:' paragraph are verbatim duplicates, which slightly muddies the otherwise clear statement.

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?

Gives real context: 'Use for research / signal context,' and routes the agent to cc.agent_strategy (paper) before any live order, plus a caution not to invent fills from this data alone. It stops short of stating when NOT to use it versus the other derivatives siblings (cc.open_interest, cc.funding_rates, cc.blofin_public), which are the tools most likely to be confused with 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description goes well beyond them: auth methods (X-Api-Key or x402 proof with HTTP 402 on anonymous calls), a per-call cost of $0.005 USDC, a 30/min rate limit, standard tier, live/near-real-time data, and an explicit 'billing, not a side effect' clarification. These are exactly the operational traits an agent needs and cannot get from annotations alone.

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 body is organized into labeled sections (Purpose, Behavior, Auth, Cost, Rate limit, Tier, Returns, Guidelines, Tags), which aids scanning. However, the entire 'Purpose' sentence is duplicated verbatim in the opening sentence and again after 'Purpose:', wasting a substantial block of tokens, and the indicator list is long enough to obscure the core instruction.

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?

An output schema exists, so return values need not be explained, yet the description still summarizes them (values, signals, divergences, crossovers per data point). Combined with auth, cost, rate limits and the paper-trading handoff, the definition covers everything needed to invoke the tool correctly; only sibling disambiguation is thin.

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 baseline is 3; the schema already documents bars, action, overlays, indicators, candles and __x_payment. The description adds only marginal meaning (default 100 bars, use 300 for overlay-consistent lookback, same code the chart draws), which is useful but largely restates the schema's enum/option lists.

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 names a concrete verb and resource — computing 25+ named technical indicators (SMA, EMA, RSI, MACD, ATR, Bollinger, Ichimoku, VWAP, etc.) on any OHLCV data, plus Smart Overlays via action=smart_overlays. That is specific enough to distinguish it from data-fetching siblings like cc.auto_fetch_market_data or cc.ma_fetch. It does not, however, contrast itself against the potentially overlapping cc.indicator_generator or cc.strategy_data_parser, so the boundary with those siblings is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The Guidelines block states the scope of use ('Compute / parse / backtest only — no live orders') and names the intended downstream step ('Feed outputs into cc.agent_strategy with force_paper=true to paper-trade'), which is actionable routing guidance. It also notes the 300-bar recommendation for smart_overlays. It stops short of explicit when-not-to-use or which sibling to prefer for raw market data, so it is clear context without full exclusion rules.

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?

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: ~1800s response caching, X-Api-Key or x402 payment auth, HTTP 402 behavior for anonymous calls, $0.001 USDC per successful call, and a 60/min rate limit. That is exactly the extra operational context an agent needs.

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 core purpose sentence and the 'Paid calls carry BloFin data only' clause are repeated verbatim within the same description, wasting roughly a third of the text. It is front-loaded and well-labeled (Purpose/Behavior/Auth/Cost/Returns/Guidelines), but the duplication is a clear structural defect.

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 an output schema present, return values need not be enumerated, yet the description still covers auth, billing, caching, rate limits, tier, and usage routing. For a paid, cached, read-only data endpoint, nothing an agent needs in order to call it correctly 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?

Schema description coverage is 100%, so both the symbol and __x_payment parameters are already documented in the schema (including 'default: all major' and the header-equivalent note). The description adds no syntax, format, or defaulting detail beyond what the schema provides, so the baseline 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 names a specific verb+resource (BloFin perpetual funding rate for a coin, percent per 8h, current plus 90-period history), so an agent knows exactly what it returns. It does not explicitly distinguish itself from data-overlapping siblings such as cc.open_interest or cc.coinglass_data, keeping it out of the 5 band.

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 gives clear context ('Use for research / signal context') and names an alternative workflow ('Pair with cc.agent_strategy (paper) before any live order'), plus a caution ('Do not invent fills from this data alone'). There are no explicit when-not-to-use exclusions, 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?

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?

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?

Adds substantial context beyond the annotations: READ-ONLY framing, ~1800s response caching, auth modes (X-Api-Key or x402 payment proof), HTTP 402 behavior for anonymous calls, $0.001 USDC cost, and a 60/min rate limit. These operational traits are exactly what annotations do not cover.

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 purpose sentence is duplicated verbatim ('Multi-period moving averages ... BloFin perpetual candles'), which wastes space. Otherwise the labeled structure (Behavior/Auth/Cost/Rate limit/Returns/Guidelines) is readable 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?

An output schema exists, so return values need not be spelled out, yet the description still notes the MA periods (7, 25, 50, 99, 200) across timeframes. Auth, cost, rate limit, and safety are all covered, leaving nothing an agent needs 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?

Schema description coverage is 100%, so the schema already documents both parameters (symbol and the optional __x_payment). The description adds no syntax or format detail for symbol beyond what the schema provides, so the baseline 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?

States a specific verb+resource: multi-period SMA/EMA at several lengths computed from BloFin perpetual candles. It clearly distinguishes itself as a moving-average data fetch, though it never explicitly differentiates from data-fetch siblings like cc.indicator_generator or cc.blofin_public. The repeated purpose sentence is redundant but the purpose itself 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?

Gives concrete usage guidance: 'Use for research / signal context', names the sibling cc.agent_strategy as a pairing, and warns 'Do not invent fills from this data alone'. It lacks an explicit when-not-to-use statement, but the routing to a companion tool is clear.

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?

Beyond the readOnly/idempotent/destructive annotations, the description discloses caching (~1800s), auth paths (X-Api-Key or x402 X-PAYMENT), a concrete cost ($0.001 USDC/call), the 402 failure mode for anonymous calls, a rate limit (60/min), and tier. It even clarifies the payment is billing rather than a side effect, which is exactly the kind of non-obvious behavior annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is sectioned (Behavior, Auth, Cost, Rate limit, Tier, Returns, Guidelines, Tags), which aids scanning, but the 'Purpose:' sentence duplicates the opening sentence verbatim — pure waste. The heavy boilerplate around auth/cost inflates length against the modest core content.

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 an output schema already present, the description need not explain return values, and it still summarizes them. Combined with auth, cost, rate-limit, caching, and safety coverage, an agent has everything needed to call this 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?

Schema description coverage is 100%, so the baseline is 3. The description mentions the return shape per requested symbol but adds no syntax, format, or interval guidance beyond what the schema already documents for symbol and interval.

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 opening sentence names a specific resource and its two sources (BloFin coin OI plus CFTC CME BTC/ETH futures OI), which is far more useful than the bare name. It stops short of differentiating from siblings like cc.funding_rates or cc.coinglass_data, so it is clear but not sibling-aware.

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 block gives context ('use for research / signal context') and names an explicit sequencing alternative ('Pair with cc.agent_strategy (paper) before any live order') plus a caveat ('Do not invent fills from this data alone'). It lacks an explicit when-not-this-tool statement, so it is clear but not exhaustive.

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?

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?

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: ~900s response caching, X-Api-Key or x402 proof auth, HTTP 402 behavior for anonymous callers, $0.001 USDC per call with free linked keys, and a 60/min rate limit. This is exactly the operational context an agent cannot infer from structured fields.

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 leading sentence and the "Purpose:" line state the identical coverage list verbatim, which is pure duplication and dilutes the front-loading. The remaining auth/cost/rate-limit lines each earn their place, so the flaw is redundancy rather than bloat.

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 an output schema present, return values need no elaboration, and the description still sketches the multi-category payload. Auth, cost, caching, rate limit and research-only intent are all covered, leaving nothing an agent needs before calling.

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?

There is only one parameter and schema coverage is 100%, so the baseline is already met; the description adds the meaning the schema implies by tying __x_payment to the X-PAYMENT header and the retry-after-402 workflow. It correctly frames it as a non-business parameter.

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 a specific resource with exhaustive scope: stock indices, metals, energy, tokenized equity perpetuals, forex, DXY (ECB reference rates) and Treasury yields. That enumeration distinguishes it cleanly from siblings like cc.funding_rates, cc.etf_flows or cc.cme_gap without opening a schema.

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?

"Use for research / signal context" plus "Pair with cc.agent_strategy (paper) before any live order" and "Do not invent fills from this data alone" give concrete usage and a named companion tool. No explicit when-not-to-use or alternative-quote-source routing, 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 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.