agentdata-mcp

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

No annotations exist; description only states the spreads and a dollar amount, but does not explain whether data is real-time, polling frequency, or if the $0.003 is a minimum spread, fee, or threshold. Behavioral traits are largely undisclosed.

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?

Single sentence, no wasted words. Information is front-loaded, succinct, and directly conveys the tool's focus.

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 and no output schema, the description is minimally complete. It names exchanges and a numerical value, but does not specify output format, data freshness, or meaning of '$0.003 USDC'. Leaves ambiguity for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters defined; schemas coverage is 100%. Baseline score of 4 is appropriate since no further parameter information is 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?

Description clearly indicates the tool provides cross-exchange spread data for specific exchanges (MEXC/Binance/Bybit/OKX) with a value ($0.003 USDC). The name 'get_arbitrage_opportunities' plus description distinguishes it from sibling tools that cover other crypto 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?

No guidance on when to use this tool versus alternatives (e.g., when looking for real-time spreads vs. historical data). No mention of prerequisites or typical contexts.

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 provided, so description carries full burden. It discloses that it returns TPS and block activity and mentions a cost, but lacks details on idempotency, rate limits, or side effects.

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?

Extremely concise single sentence with no superfluous words. The cost note is relevant and efficiently placed.

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 parameters and no output schema, the description is functional but lacks detail on what 'block activity' entails (e.g., block count, time range). It hints at cost but doesn't explain data freshness or format.

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?

No parameters exist, so schema coverage is 100%. Description adds no parameter info beyond the schema, which is appropriate given zero 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?

Description clearly states it retrieves Base network TPS and block activity, with a cost note. It distinguishes from sibling market data tools by focusing on Base network.

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?

No guidance on when to use this tool vs alternatives. The description implies use for Base network metrics but does not provide explicit context or exclusions.

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

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

With no annotations, the description partially covers behavior: it notes the time window (30-day) and cost ($0.001 USDC). However, it does not disclose auth requirements, rate limits, or whether the tool is read-only. The scope of assets is ambiguous.

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?

Single sentence with no extraneous information. Front-loaded with key intent. Every word serves a purpose.

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 too sparse given the lack of output schema and parameters. It fails to explain what assets are included, what the output looks like, or any constraints. More context is needed for effective use.

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?

No parameters exist, so schema coverage is effectively 100%. The description adds no parameter details, but none are needed. Baseline of 4 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 provides a 30-day price correlation matrix, with cost information. It distinguishes from sibling tools like get_crypto_prices or get_defi_yields which serve different purposes.

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?

No guidance on when to use this tool versus alternatives. No exclusions or prerequisites mentioned. The description does not help the agent decide contextually.

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, the description must disclose behavioral traits. It only states 'real-time' but does not detail update frequency, latency, rate limits, or other behaviors. Minimal 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?

A single sentence with no unnecessary words. It is front-loaded with the core purpose and immediately useful for an agent.

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 output schema and no parameters, the description covers the basic purpose and assets. However, it omits output format, units, and clarification on the USDC notation, leaving some ambiguity.

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?

No parameters exist, so baseline is 4. The description adds value by listing the specific assets covered, which is not present in 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 it provides real-time prices for specific cryptocurrencies (BTC, ETH, SOL, BNB, XRP). The parenthetical '($0.001 USDC)' is slightly ambiguous but overall distinguishes it from sibling tools like get_arbitrage_opportunities or get_correlation.

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?

No guidance is given on when to use this tool versus siblings or alternatives. The description does not specify any context of use or exclusions.

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

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

The description includes a cost hint ($0.002 USDC) which adds some behavioral context, but no annotations exist. Other traits like rate limits, data freshness, or authentication needs are missing.

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 very concise, a single sentence, and front-loaded with the main purpose. It could be slightly more structured but earns its place for brevity.

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 output schema and no params, the description should explain what 'top' yields means, the time frame, and data format. It only mentions protocols and cost, leaving the agent with limited understanding of the output.

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, so schema coverage is trivially 100%. Per the rubric, no parameters baseline is 4. The description does not need to add parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly indicates the tool returns top DeFi yields and lists specific protocols (Aave, Compound, Morpho, Pendle). However, it lacks a verb and does not differentiate from siblings like get_market_overview or get_crypto_prices.

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?

No guidance is provided on when to use this tool versus alternatives. Among siblings, there are similar tools like get_market_overview, but no when-to-use or when-not-to-use advice is given.

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, the description carries full burden for behavioral disclosure. It only mentions a price comparison and a cost figure, but does not disclose whether data is real-time, historical, or requires credentials.

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 concise at one sentence, but the inclusion of a specific cost figure may be unnecessary and could confuse. It lacks additional structure like a title.

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 parameterless tool, the description is minimal and does not explain what exactly is compared, time frame, or the meaning of the cost. It leaves missing context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters with 100% coverage, so the description does not need to add parameter semantics. The tool is straightforward with no inputs.

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 comparison between DEX and CEX prices, which distinguishes it from siblings like get_crypto_prices. However, the inclusion of '$0.003 USDC' is ambiguous and could be misinterpreted as a token pair rather than a cost.

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?

No guidance on when to use this tool versus alternatives like get_arbitrage_opportunities. The description does not provide context for its appropriate use case.

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 full burden for behavioral transparency. It hints at a cost ($0.001 USDC) but does not clarify if it is a per-request fee, subscription, or other. No mention of data frequency, historical range, authentication requirements, or output format. The brief description leaves significant unknowns.

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 a single, highly concise sentence that conveys the essential information without any unnecessary words. It front-loads the purpose and includes a key detail (cost hint) efficiently.

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 tool with no output schema, the description is adequate but not fully complete. It tells what data is returned and hints at cost, but lacks information about data freshness, update frequency, or whether signals are bullish/bearish. Could be improved with a sentence on update cadence.

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, so the baseline is 4. The description does not need to add parameter information. It correctly describes the tool as taking no inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides 'Perpetual funding rates with long/short signals ($0.001 USDC)'. It uses a specific verb ('get') and resource ('funding rates'), and distinguishes itself from sibling tools like 'get_crypto_prices' or 'get_defi_yields' by specifying the unique data type.

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?

No guidance on when to use this tool versus alternatives. Does not mention when it is appropriate or inappropriate, nor reference sibling tools like 'get_arbitrage_opportunities' or 'get_market_overview'. The agent has no context for 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?

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or data freshness. The description carries the full burden but only states functionality, not behavior.

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 a single, concise sentence that is front-loaded with the core purpose. Every word contributes to understanding, with no wasted text.

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 tool with no output schema, the description adequately states what data is provided (multi-chain gas prices) and the unit ($0.001 USDC). However, it does not specify the return format or any additional context, leaving some ambiguity.

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 are no parameters, so the schema coverage is trivially 100%. The baseline is 4, and the description adds no parameter info because none is needed. The description does add context about chains and fee unit, which is not parameter-related.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides multi-chain gas prices for Base, ETH, and SOL, with a fee unit specified. It distinguishes itself from sibling tools like get_crypto_prices or get_defi_yields, though the verb 'get' is implied rather than explicit.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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, the description must disclose behavior. It only mentions cost ($0.005 USDC) but omits rate limits, pagination, data coverage, or other operational traits.

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?

Short and to the point, but under-specified. Conciseness should not come at the expense of critical information.

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 3 parameters, no output schema, and 0% schema description, the description fails to explain what OHLCV stands for, time intervals, or return format. Completely inadequate.

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?

Parameter schema coverage is 0%, and description provides no meaning for 'limit', 'symbol', or 'interval'. Agent cannot understand parameter roles.

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 'Historical OHLCV candles', clearly indicating it fetches historical price data. However, it does not differentiate from sibling tools like get_crypto_prices or get_technical_indicators, and includes irrelevant cost info.

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?

No guidance on when to use this tool versus alternatives. Lacks context for tool selection or 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?

No annotations are present, so the description must bear full behavioral disclosure. It does not specify if the estimates are real-time or historical, nor any authentication or rate limits. The description only hints at output content.

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?

A single concise sentence of 9 words that efficiently conveys the core purpose. No 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?

Given the simple nature (no params, no output schema), the description is reasonably complete but lacks context on what the '$0.002 USDC' represents or how the estimates are derived. Slightly below adequate for a standalone description.

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?

No parameters exist, so schema coverage is 100%. Baseline is 4. The description adds context by specifying the leverage levels and price point for the estimated zones, enhancing understanding of what the tool returns.

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?

Clearly states it provides estimated liquidation zones for specific leverage levels (5x, 10x, 20x) at a price of $0.002 USDC. Differentiates from sibling tools which cover other market data like arbitrage, volatility, and sentiment.

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?

No explicit guidance on when to use this tool versus alternatives. The context implies it's for liquidation analysis, but no when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries full burden. It does not disclose crucial behaviors such as whether the tool is read-only, if it incurs cost (the '$0.002 USDC' is ambiguous), rate limits, or data freshness. For a tool returning market data, these are significant omissions.

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 a single sentence, achieving conciseness. However, the inclusion of '$0.002 USDC' is somewhat extraneous and may be better placed in a cost field if available. The structure is otherwise effective.

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 no parameters or output schema, the description provides a basic understanding of what it does. However, it lacks details on the output format, update frequency, or any prerequisites. For a simple tool, it is minimally adequate but not fully 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 no parameters, so schema coverage is 100%. The description adds meaning by specifying the tool returns 'sentiment + arb signals', which is not evident from the empty schema. This helps the agent understand the output composition, exceeding the baseline 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 provides a 'full market overview with sentiment + arb signals', indicating a combined view of market sentiment and arbitrage opportunities. However, the inclusion of '$0.002 USDC' is ambiguous (possibly cost) and detracts from clarity. It differentiates from siblings like get_sentiment and get_arbitrage_opportunities but could be more explicit.

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?

No explicit guidelines on when to use this tool versus alternatives. The description implies it is for a broad market overview with both sentiment and arbitrage signals, but does not state specific contexts or exclusions. The presence of sibling tools suggests users might need to choose, but no guidance 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?

No annotations exist, so the description carries the full burden. It only hints at cost ($0.001 USDC) but does not disclose whether the tool is read-only, requires authentication, or has side effects. Minimal behavioral information is provided.

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 a single sentence, efficient and front-loaded with key content. However, it could be slightly more structured with a brief output format hint, but overall it is concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should explain return values. It mentions 'Fear & Greed + composite sentiment' but provides no format, structure, or example. For a tool with no parameters, this is still incomplete.

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 are no parameters in the input schema, so coverage is 100%. The description adds no parameter information, but this is acceptable since there are none to describe. Baseline is set to 3 per the high coverage guideline.

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 mentions 'Fear & Greed + composite sentiment', which clearly indicates the tool returns sentiment data. However, it lacks an explicit verb like 'retrieves', relying on the tool name 'get_sentiment' for clarity. It is specific and distinct from sibling tools like get_technical_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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparison with sibling tools such as get_market_overview.

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, the description bears full responsibility for behavioral disclosure. It mentions a threshold ($0.001 USDC) but fails to explain what 'depeg monitoring' entails operationally—such as whether it returns a boolean, numeric delta, or how frequently data is updated. This is insufficient for an agent to predict outcomes.

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 a single, front-loaded sentence conveying the core purpose without extraneous words. Every part earns its place, making it highly 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?

Despite having no parameters, the tool lacks an output schema. The description does not specify the return format (e.g., boolean, numeric, alert message) or explain what constitutes a depeg event. For a monitoring tool, this omission leaves agents without critical success criteria.

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 are no parameters, so schema coverage is 100%. The description adds value by clarifying the tool monitors specific stablecoins and a threshold, which enriches the zero-parameter context beyond the empty 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 specifies the tool monitors depeg of USDC/DAI with a precise threshold of $0.001. It distinctly identifies the resources and action, setting it apart from sibling tools like get_crypto_prices or get_market_overview.

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 use for stablecoin depeg health but offers no explicit guidance on when to use this tool versus alternatives or any prerequisites. Given the uniqueness among siblings, the implied usage is adequate but lacks explicit direction.

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 exist, and the description only hints at the algorithm ('fractal analysis') and cost ('$0.003 USDC'). It fails to disclose output format, number of levels, timeframes, or any side effects. The cost hint is useful but insufficient.

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 extremely short (one sentence) but the phrasing 'S/R levels' is jargon that may not be immediately clear to all agents. It is concise but compromises clarity.

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 output schema and minimal description, the tool lacks necessary context about return values, interpretation of results, or usage examples. A more complete description would include what the output looks like and how to interpret the levels.

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 one parameter 'symbol' with 0% coverage, and the description does not mention it at all. The agent receives no explanation of what the parameter does or how to use it, forcing reliance on the parameter name alone.

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 'S/R levels via fractal analysis' clearly indicates the tool computes support/resistance levels and specifies the method. However, it does not distinguish this tool from sibling tools like get_technical_indicators that may also provide similar 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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The agent receives no help in deciding to invoke this tool over siblings.

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

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

The description includes a cost ($0.002 USDC) but does not disclose other behavioral traits such as read-only nature, rate limits, or data freshness. With no annotations, the description carries full burden and fails to provide sufficient 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 very brief (one sentence), which is concise, but it lacks structure and does not front-load key information. It could be expanded to include parameter guidance or usage context without losing 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?

Given 16 sibling tools and no output schema, the description is insufficient. It does not explain return values, how the indicators are computed, or how this tool differs from other analytical tools like get_volatility or get_support_resistance.

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% description coverage and the description does not mention the parameters (symbol, interval) at all, offering no additional meaning despite a low 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 lists specific indicators (RSI, MACD, Bollinger Bands, ATR) and a cost, implying the tool retrieves these indicators. However, it lacks a clear verb and does not differentiate from sibling tools like get_volatility or get_support_resistance that may also return technical 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?

No guidance is provided on when to use this tool versus alternatives such as get_volatility or get_correlation. There is no mention of prerequisites or exclusions, leaving the agent to guess the appropriate context.

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, the description carries full burden for behavioral disclosure. It only states the output (24h volatility) but omits details such as data source, update frequency, whether it's real-time or historical, or any edge cases (e.g., missing data). This is insufficient for a tool with no other structured behavioral 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 very short and front-loaded with key information (timeframe, assets). It wastes no words, but could be slightly more structured (e.g., specifying the return format). On balance, it is efficient and clear.

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 parameters and no output schema, the description adequately conveys the tool's purpose. However, it does not clarify the return format (e.g., object with per-asset values) or any precision details. It is minimally complete but could mislead if the output structure is not obvious.

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 are zero parameters, so the baseline is 4 per evaluation rules. The description does not need to add param-specific meaning beyond what the empty schema provides, and it correctly implies no user input is 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 it retrieves 24-hour volatility for three specific assets (BTC, ETH, SOL) and includes the price unit ($0.001 USDC). This provides a specific verb-resource combination and distinguishes from siblings like get_correlation or get_technical_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?

No guidance on when to use this tool versus alternatives. The description does not mention contexts, prerequisites, or exclusions. Users must infer usage from the tool name alone.

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