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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (8 indicators with scores, interpretations, and zone classifications) and its purpose (long-term positioning and cycle-aware strategies). While it doesn't mention rate limits or authentication needs, it provides substantial behavioral context for a read-only data retrieval tool.

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 efficiently structured in three sentences: first states the core purpose and lists indicators, second describes the data format, third provides usage context. Every sentence adds value with zero redundant information. It's appropriately sized for the tool's complexity.

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 parameterless tool with no output schema, the description provides comprehensive context about what data is returned (8 specific indicators with score ranges, interpretations, and zone classifications) and when to use it. The main gap is the lack of information about return format/structure, but given the tool's relative simplicity, the description is largely 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 tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It focuses instead on what the tool returns, which is appropriate for a parameterless query tool.

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: 'Get all 8 BTC cycle indicators that help determine where Bitcoin is in its market cycle.' It specifies the exact indicators returned (MVRV Z-Score, NUPL, etc.) and distinguishes this from sibling tools like get_fear_greed or get_market_health, which provide different types of market 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: 'Useful for long-term positioning and cycle-aware trading strategies.' This gives the agent guidance that this tool is for Bitcoin market cycle analysis rather than short-term metrics. However, it doesn't explicitly state when NOT to use it or name specific alternatives among 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a read operation ('Get') and details the returned data, which covers basic behavior. However, it lacks information on potential errors (e.g., invalid symbols), rate limits, authentication needs, or data freshness, leaving gaps in transparency for a tool with no 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 front-loaded with the core purpose, followed by details on returned data and usage guidance. Both sentences are essential: the first defines the tool's function and output, and the second provides critical context for tool selection. There is no wasted text, making it highly efficient and well-structured.

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 (single parameter, no output schema, no annotations), the description is largely complete. It covers purpose, output details, and usage guidelines effectively. However, it lacks explicit information on error handling or data sources, which could be useful for an agent. With no output schema, the description's detail on return values is beneficial but not exhaustive.

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% description coverage, so the schema already documents the single parameter 'symbol' with its type and format. The description adds value by providing context: it explains the parameter's role ('by symbol'), gives examples (BTC, ETH, SOL), and clarifies that symbols should be exact, which enhances understanding beyond the schema's technical specification.

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 ('Get') and resource ('detailed profile for a specific cryptocurrency by symbol'), and distinguishes it from sibling tools by mentioning 'search_coins' as an alternative for symbol uncertainty. It explicitly lists the returned data fields (price, market cap, changes, etc.), making the purpose highly specific and differentiated.

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 on when to use this tool vs. alternatives: 'Use search_coins first if you're unsure of the exact symbol.' This directly addresses the sibling tool 'search_coins' and gives a clear conditional for tool selection, which is optimal for agent decision-making.

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?

No annotations are provided, so the description carries the full burden. It mentions the tool returns 'a full daily snapshot' and is 'efficient,' implying it's a read-only operation with no destructive effects, but lacks details on rate limits, authentication needs, data freshness, or error handling. It adds some context about filtering but doesn't fully disclose behavioral traits beyond basic functionality.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a detailed list of returned data, then efficiency note and parameter guidance. Every sentence adds value without redundancy, making it highly concise and well-structured for quick comprehension.

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 (returns multiple data types) and no annotations or output schema, the description does well by listing all returned components and providing parameter guidance. However, it lacks details on response format, pagination, or error cases, which could be important for a tool with such broad scope. It's mostly complete but has minor 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic meaning of the exchange parameter: 'Use exchange='all' for unfiltered data or 'hyperliquid'/'binance_spot' to filter coin lists,' which clarifies the practical impact beyond the schema's enum and description. This enhances understanding, warranting a score above 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's purpose with specific verbs ('Get a full daily snapshot') and resources ('entire crypto market'), listing comprehensive data types returned. It explicitly distinguishes from siblings by noting this provides 'all in a single response' versus the more granular sibling tools like get_fear_greed or get_coin_profile.

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: 'This is the most efficient way to get a broad market overview' indicates when to use it (for comprehensive data), and the exchange parameter explanation with 'all' for unfiltered vs. specific exchanges for filtered coin lists gives clear context for parameter selection, though it doesn't explicitly name when not to use it versus 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about the data's significance ('Consistent positive flows signal institutional demand; negative flows signal institutional selling') and historical relevance ('BTC ETF flows have been a major market driver since January 2024'), but does not detail operational aspects like data freshness, rate limits, or error handling.

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 appropriately sized and front-loaded, starting with the core functionality. The first sentence covers the purpose, and subsequent sentences add valuable context without redundancy. However, the historical note about BTC flows, while informative, could be considered slightly extraneous for pure tool selection.

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 low complexity (1 parameter, no output schema, no annotations), the description is largely complete. It explains what the tool does, why it's useful, and provides context. The main gap is the lack of output details, but with no output schema, this is a minor omission for a simple data retrieval 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 description coverage is 100%, with the parameter 'asset' fully documented in the schema (enum values and description). The description adds no additional parameter semantics beyond what the schema provides, such as explaining the implications of choosing different assets, so it meets the baseline score of 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?

The description clearly states the tool's purpose with specific verbs ('Get ETF flow data') and resources ('BTC, ETH, SOL, or XRP spot ETFs'), distinguishing it from siblings by focusing on ETF flows rather than other crypto metrics like fear/greed indices or funding rates. It explicitly mentions what data is shown ('daily net inflows/outflows across all major ETF issuers').

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—to analyze institutional demand or selling signals for specific assets via ETF flows—and implies usage by mentioning market drivers. However, it does not explicitly state when not to use it or name alternatives among sibling tools, such as 'get_stablecoin_flows' for different flow types.

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?

With no annotations provided, the description carries the full burden and does so well. It discloses behavioral traits: the tool returns a sentiment score with classifications, includes a per-source breakdown, and offers interpretive guidance on market implications (e.g., Extreme Fear signals buying opportunities). No contradictions exist.

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, followed by detailed classifications and practical insights. Every sentence adds value—defining the index, explaining its scale, detailing classifications, and providing market context—with zero waste.

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 (0 parameters, no output schema), the description is nearly complete. It explains what the tool returns and its significance, though it could briefly mention the data format or update frequency for full completeness.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics, explaining the score range and classifications, which adds 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 the tool's purpose: to retrieve the Crypto Fear & Greed Index, specifying it's a multi-source averaged sentiment score with a 0-100 range. It distinguishes this from siblings by focusing on market sentiment rather than specific assets, cycles, or financial metrics.

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—to assess market sentiment—and implicitly suggests alternatives by mentioning classifications like 'buying opportunities' or 'overheated markets.' However, it doesn't explicitly name when not to use it or direct alternatives among 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?

With no annotations provided, the description carries full burden and adds valuable behavioral context: it explains what funding rates mean (longs/shorts payments), market implications (bullish/bearish crowding, corrections, capitulation), and lists example exchanges covered. However, it lacks details on rate limits, authentication needs, or data freshness.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by explanatory context and coverage details. Every sentence adds value 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 no annotations and no output schema, the description provides good context on behavior and coverage, but could be more complete by specifying return format (e.g., structured data with timestamps) or error handling for a tool with 3 parameters.

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 does not add parameter-specific semantics beyond the schema, such as explaining default behaviors for omitted parameters or providing additional examples for exchange names.

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 specific verb ('Get') and resource ('cross-exchange perpetual funding rates'), and distinguishes it from siblings by focusing on funding rates rather than other market data like liquidations, open interest, or ETF flows.

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 implies usage by explaining the significance of positive/negative funding rates and extreme values, but does not explicitly state when to use this tool versus alternatives like get_open_interest or get_liquidations for related market insights.

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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns data over a 24-hour period and explains the significance of liquidation volumes and ratios, adding useful behavioral context. However, it omits details like rate limits, authentication requirements, or data freshness, which are important for a data-fetching tool in a financial 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 efficiently structured in three sentences: the first states the purpose, the second explains the data's significance, and the third provides usage context. It avoids redundancy and is front-loaded with the core functionality, though it could be slightly more concise by integrating the usage hint into the first sentence.

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 no annotations and no output schema, the description provides adequate context for a data retrieval tool by explaining what the data represents and its analytical value. However, it lacks details on output format (e.g., structure of returned data, units like USD or BTC), which would be crucial for an agent to process the results effectively, leaving some gaps in completeness.

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 three parameters (exchange, type, limit) with clear descriptions. The description does not add any parameter-specific information beyond what the schema provides, such as examples for the 'type' filter beyond 'perps' or default behaviors for omitted parameters, resulting in a baseline score of 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?

The description clearly states the specific action ('Get cross-exchange liquidation data') and resource ('long and short liquidation volumes over 24h'). It distinguishes from siblings by focusing on liquidation metrics rather than other market data like funding rates, open interest, or ETF flows, making its purpose 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 implies usage for 'gauging leveraged positioning pain' and interpreting liquidation ratios, providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., get_funding_rates for funding pressure or get_market_health for broader stress indicators), leaving the agent to infer based on general market analysis needs.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what data is returned (macro indicators) and adds context about market correlations (e.g., dollar strength impact on crypto), which is useful beyond a basic read operation. However, it lacks details on data sources, update frequency, rate limits, or error handling, leaving gaps in behavioral understanding for a tool with no 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 two sentences: the first states the purpose and lists indicators, and the second provides market context. While informative, the second sentence could be more tightly integrated or omitted if not essential for tool selection. The structure is front-loaded with the core functionality, but the market correlation details might be extraneous for concise tool invocation guidance.

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 (simple read operation with no parameters) and lack of annotations or output schema, the description is moderately complete. It specifies what data is returned but doesn't detail the format (e.g., numerical values, timestamps) or potential errors. For a no-parameter tool, this is adequate but leaves room for improvement in output clarification, especially without an output schema.

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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps, and it appropriately focuses on the tool's output semantics by listing the indicators retrieved. This meets the baseline for tools with no parameters.

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: to retrieve macroeconomic indicators relevant to crypto markets, specifically listing EUR/USD exchange rate, gold price, and US treasury yields. It distinguishes itself from siblings by focusing on macroeconomic data rather than crypto-specific metrics like funding rates or market health. However, it doesn't explicitly mention the verb 'retrieve' or 'fetch,' though this is implied.

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 mentions that the indicators are 'relevant to crypto markets' but doesn't specify scenarios where this tool is preferred over siblings like get_market_health or get_fear_greed. The context about market correlations (e.g., dollar strength being bearish for crypto) is informative but doesn't translate into actionable usage instructions.

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?

With no annotations provided, the description carries the full burden and does well by explaining the scoring system (0-100 dual-score), return values (total_score, long_term_score, etc.), and the tool's purpose for market regime assessment. It doesn't mention rate limits or authentication needs, but provides 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?

Two sentences with zero waste: the first explains what the tool returns, the second provides usage guidance. Every element adds value 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 no annotations, no output schema, and 0 parameters, the description is quite complete—it explains the scoring system, return values, and usage context. It could slightly improve by mentioning the data source or update frequency, but covers the essentials well.

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 0 parameters with 100% schema coverage, so the baseline is 4. The description appropriately doesn't discuss parameters, focusing instead on what the tool returns and when to use it.

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 ('Get') and resource ('market health summary'), and distinguishes it from siblings by explaining it provides a dual-score system for overall market assessment rather than specific metrics like ETF flows or fear/greed indices.

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?

Explicitly states when to use this tool: 'to quickly assess the overall market regime before making trading decisions.' This provides clear context for its application versus alternatives that might offer more granular data.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (per-exchange OI in USD with 24h change percentages) and provides context on how to interpret OI trends (e.g., rising OI with rising price indicates new money entering). However, it lacks details on rate limits, error handling, or data freshness.

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 efficiently structured in two sentences: the first defines the tool's purpose and output, and the second explains OI interpretation for market analysis. Every sentence adds value without redundancy, making it front-loaded and easy to parse.

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 read-only data retrieval tool with no annotations and no output schema, the description is reasonably complete. It covers the tool's purpose, output format, and interpretive context. However, it could be more complete by mentioning data sources, update frequency, or example use cases, given the complexity of financial data analysis.

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 three parameters (exchange, type, limit) with clear descriptions. The description does not add any parameter-specific semantics beyond what the schema provides, such as example values for 'type' beyond 'perps' or clarification on 'limit' behavior. Baseline score of 3 is appropriate given high schema coverage.

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 retrieves cross-exchange open interest data for perpetual futures contracts, specifying it returns per-exchange OI in USD with 24h change percentages. It distinguishes from siblings by focusing on open interest metrics rather than other market data 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 implies usage for analyzing market trends through OI patterns (e.g., rising OI with price changes indicating trend continuation or bearish signals), but it does not explicitly state when to use this tool versus alternatives like get_funding_rates or get_liquidations for related market insights. No exclusions or prerequisites are mentioned.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what data is returned and provides interpretive context about the metrics (bearish/bullish signals, max pain theory). However, it doesn't mention potential limitations like data freshness, source reliability, or rate limits that would be helpful for a read-only data tool.

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 efficiently structured with two sentences: the first states what data is returned, the second provides interpretive context. Every sentence adds value, though the interpretive guidance could be considered slightly beyond the minimal required scope for a pure data retrieval tool.

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 zero-parameter read-only tool with no output schema, the description provides good contextual completeness. It clearly states what data is returned and adds valuable interpretive context. The main gap is the lack of information about data source, freshness, or format, which would help an agent understand the reliability and structure of the returned data.

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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing non-existent parameters, focusing instead on what the tool returns and how to interpret the data.

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 specific action ('Get BTC options market data') and lists the exact data points returned (total open interest, volume, put/call ratio, max pain price). It distinguishes itself from siblings like 'get_open_interest' by focusing specifically on options market data rather than general 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 implies usage context through its explanation of what the data means (e.g., 'high put/call ratio (>1) suggests bearish hedging'), but it doesn't explicitly state when to use this tool versus alternatives like 'get_open_interest' or 'get_market_health'. No explicit when-not-to-use guidance or prerequisite information is provided.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what data is returned (market cap, flow data, per-stablecoin breakdown) and the interpretation of that data, but doesn't mention technical behaviors like rate limits, data freshness, error conditions, or authentication requirements. The description adds value by explaining the economic interpretation but lacks operational details.

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 perfectly front-loaded with the core purpose in the first clause, followed by explanatory context and detailed output information. Every sentence adds value: the first states what the tool does, the second explains why it matters, the third provides interpretation guidance, and the fourth details the return data structure. Zero wasted words.

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 parameterless tool with no output schema, the description provides excellent context about what data is returned and how to interpret it. It explains the economic significance and lists the specific data points (total market cap, 14-day/90-day flows, per-stablecoin breakdown). The main gap is the lack of output format details, but given the tool's relative simplicity, the description is quite 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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing parameters that don't exist, which is efficient and correct for a parameterless tool.

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 specific verbs ('Get stablecoin market cap and flow data') and resource ('stablecoin'). It distinguishes itself from sibling tools by focusing specifically on stablecoin metrics rather than other crypto data like BTC cycles, ETF flows, or market health indicators.

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 ('a proxy for capital entering or leaving crypto') and explains the significance of the data ('Rising stablecoin market cap signals new capital inflows (bullish). Declining market cap signals capital outflows (bearish)'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling 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?

No annotations are provided, so the description carries the full burden. It discloses the return format ('symbol, name, market cap rank, and current price') which is valuable behavioral information. However, it doesn't mention limitations like result count, pagination, or error conditions, leaving some behavioral aspects unspecified.

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 perfectly concise with two sentences that each serve distinct purposes: the first explains what the tool does and returns, the second provides usage guidance. There is zero wasted text, and it's front-loaded with the core functionality.

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 simple search tool with one parameter (fully documented in schema) and no output schema, the description provides good context: it explains the purpose, return format, and usage relationship with another tool. However, without annotations or output schema, it could benefit from mentioning any limitations (like max results) or error cases for full completeness.

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 fully documents the single parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain search matching rules, case sensitivity, or examples beyond those already in the schema). Baseline 3 is appropriate when the schema does all the work.

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 specific verbs ('Search for cryptocurrencies') and resources ('by name or symbol'), and distinguishes it from sibling tools by mentioning its role in finding symbols before calling get_coin_profile. It explicitly identifies what it does beyond just restating the name.

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 on when to use this tool ('when you need to find the correct symbol for a coin before calling get_coin_profile'), naming a specific alternative (get_coin_profile) and clarifying the workflow relationship. This gives clear context for tool selection.

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