AgentFeed

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

With no annotations provided, the description carries the full burden of disclosure. It transparently mentions the $0.01 USDC cost per call and the Solana mainnet/x402 execution context, plus outlines the output components. It does not detail error behavior or return formatting, but the cost and network disclosure add meaningful transparency beyond the schema.

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 defines what the tool returns, the second states the cost and network. Every word is informative, with no filler or redundancy, making it highly concise and easy to scan.

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 (one parameter, no output schema), the description covers the essential return components (premium/discount, contango/backwardation, funding context) and the cost. It lacks details on output formatting or possible errors, but for a single-purpose data fetch, this 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 schema already fully documents the only parameter 'symbol' with example 'SOLUSDT', so the baseline is 3. The description's 'any USDT pair' reinforces universality but adds no new format or syntax details beyond the schema's existing example.

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 perp-vs-spot basis (premium/discount %, contango/backwardation, funding context) for USDT pairs. This is distinct from sibling funding tools like get_funding_rate and get_funding_cross, which focus on funding data, making the 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 when to use this tool: whenever basis data for a USDT perp is needed. However, it does not explicitly name alternatives or state when not to use it, though the clear metric focus provides enough context without further 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 carries the full burden and does well by disclosing the $0.001 USDC cost per call, the x402/Solana mainnet execution, and the Pyth oracle source. It does not mention rate limits, failure handling, or balance requirements, but the cost and network details are significant transparent disclosures.

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, front-loads the main purpose, and includes only essential operational details (oracle, cost, network). Every word adds value, and there is no fluff or 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 zero-parameter, simple price-fetching tool, the description is complete: it specifies the asset pair, the output concept (price with confidence interval), the data source, and the cost implication. There is no output schema, but the description adequately conveys what the caller gets and the side effect.

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 coverage is effectively 100% with an empty properties object. The description adds relevant context about the price source and cost, so no parameter documentation is needed; the baseline 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 the live BTC/USD spot price with a confidence interval, naming the specific asset pair and data source (Pyth oracle). This distinguishes it from sibling tools like get_sol_price and general market 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 implies this tool should be used when a live BTC/USD spot price is needed, but it does not explicitly state when to use it over alternatives or mention exclusions. No explicit contrast with sibling tools or contextual 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 are provided, so the description carries the full burden. It discloses the cost per call ($0.01 USDC), the live nature ('active NOW'), and the empty array behavior, which are important behavioral details 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 three sentences, front-loaded with the core purpose and output, then alternative guidance and cost. Every sentence adds value with no redundancy, 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?

For a tool with no output schema, it adequately explains the return shape (cascades with fields), empty array behavior, and cost. It lacks an example or more detail on severity thresholds, but is sufficiently complete for an agent to invoke and interpret results.

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 each parameter has a description, so the description adds little beyond the schema. It mentions 'window' indirectly via 'active NOW' and 'window' in the empty-array explanation, but does not enhance the parameter understanding.

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

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

The description clearly states the tool is a 'Liquidation cascade detector for the 5 majors' with specific output fields (symbol, side, USD total, prints, duration, severity). It differentiates from the sibling tool get_cascade_scan by explicitly stating the scope difference.

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 explicitly directs users to 'use get_cascade_scan' for all ~600 USDT perps across 3 exchanges, providing a clear when-not-to-use condition. This helps the agent select the correct tool based on scope.

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 the full burden of disclosing behaviors. It reveals that the tool returns a probability based on impossible-to-reconstruct historical data, includes self-settling instructions, declines when history is insufficient, and costs $0.02 USDC. This exceeds typical disclosure and provides significant behavioral context beyond the schema.

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 longer than a typical one-liner but every sentence earns its place: it defines the forecast, explains calibration, outlines return contents, notes decline behavior, and discloses cost. It is front-loaded with the most critical 'forward-looking' distinction. It could be slightly more compact, but it avoids 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 complexity of a probabilistic forecast with no output schema, the description explains what the answer includes (exact question, threshold, window, historical occurrences, self-settling instructions) and covers edge cases like insufficient history. It does not provide a concrete example output, but it sufficiently conveys the tool's behavior and return value composition for an agent to invoke it 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 input schema already describes both parameters fully (100% coverage). The description does not add parameter-specific details beyond what the schema states, such as examples or differences between single and batch calls. Per the rubric, the baseline is 3 when schema coverage is high, and this description does not rise above that 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 states a specific, forward-looking purpose: 'Returns the probability that a symbol will liquidate more in the NEXT 15 minutes than its own 90th-percentile 15-minute window.' It explicitly distinguishes itself from history tools by stating 'not a description of what already happened,' which clearly differentiates it from siblings like get_cascade_history.

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: it is forward-looking, not historical, and carries a cost. It implicitly excludes past-event queries by emphasizing the forward-looking nature. However, it does not explicitly name alternative tools (e.g., get_cascade_forecast_free) or state when to prefer them, so it falls short of explicit when-to-use vs alternatives 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?

With no annotations, the description carries the behavioral disclosure. It transparently states it is free, full-quality, with no delay and nothing withheld, addressing potential concerns about free tiers. However, it does not describe the return format or any rate limits, 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 concise with two informative sentences, but the final 'Free.' is redundant given the opening 'FREE taster' and the mention of paying for coverage. Still, it is efficiently worded and front-loads key 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?

Given the simplicity of a zero-parameter tool with no annotations or output schema, the description provides adequate context about its purpose and usage. It could be improved by explaining what the forecast output contains, but it is far from insufficient.

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 the input schema is empty. The description adds no parameter-specific details, but none are needed. The baseline score of 4 applies 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 provides the full-quality liquidation forecast for SOL, distinguishing it from the broader paid coverage of ~345 symbols referenced via the sibling context. The phrase 'FREE taster' clarifies it's a limited free version, 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?

It explicitly suggests using this tool to check calibration before purchasing coverage for other symbols, providing a clear usage context. However, it does not name the specific alternative tool (e.g., get_cascade_forecast), so the guidance is slightly less explicit than ideal.

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 discloses critical behavioral details: the cost ($0.03 USDC per call via x402 on Solana mainnet), the 72-hour lookback window, and the output nature (clustered same-side events with start/end, prints, totals). It lacks explicit rate limits or error behavior, but the cost and data-source context go well beyond a minimal description.

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 deliver the core purpose, differentiate from a sibling, and state cost—all without waste. The structure front-loads the what, then the when-to-use contrast, then the pricing—efficient and scannable.

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

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

For a tool with 5 optional parameters, no output schema, and no annotations, the description covers purpose, time range, cost, and key output fields. It does not specify the exact return structure (e.g., array of events) or error cases, but it provides sufficient information for an agent to select and invoke the tool correctly in typical usage.

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 80% (4 of 5 parameters documented), so baseline is 3. The description adds behavioral context by explaining what an 'event' is (clustered same-side flush events) and tying the time window to hours, which enriches the meaning of gap_s and hours beyond their schema descriptions. The scope parameter is not described in schema, but the description does not specifically address it; still, the added context earns a point 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 reconstructs PAST liquidation cascades from the tape, listing specific output components (start/end, prints, USD total, peak print). It explicitly contrasts with the sibling get_cascade_alert, which tells you NOW, thereby distinguishing the historical scope of this tool.

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 gives explicit guidance: use this for past cascades up to 72h back, while get_cascade_alert is for real-time alerts. This directly addresses when to use the tool versus a key alternative, and implies the time-based selection 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?

With no annotations, the description carries the full burden and discloses key behaviors: the exchanges covered, the unique data source ('Bybit is the only complete unthrottled liquidation tape'), cost ($0.05 USDC per call), and return fields. It doesn't mention response format or error cases, but the essential behavioral traits are present.

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

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

The description is three sentences, front-loaded with the main purpose, and every sentence earns its place: intent, unique data source reasoning, and return/cost details. It includes some promotional phrasing but remains tight and 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?

For a paid scan tool with 3 optional params and no output schema, the description is quite complete: it defines the universe, exchanges, output fields, and cost. It doesn't specify pagination or threshold defaults, but the schema covers parameter constraints, making this sufficient for an agent 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?

All three parameters are fully described in the schema (100% coverage), so baseline is 3. The description does not add meaning beyond the schema's descriptions of window, min_usd, and min_events, but it also does not need to since the schema is sufficient.

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 'detects liquidation cascades' across ~600 USDT perps on Bybit, OKX, and Binance, with a specific verb and resource. It distinguishes from siblings by emphasizing 'FULL-UNIVERSE' and 'not just majors,' and lists output fields (symbol, side, USD total, prints, duration, severity).

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 broad multi-exchange cascade scanning and highlights uniqueness ('not available anywhere else'). It provides clear context for when to use it, but it does not explicitly name alternatives or state when-not-to-use, so it stops short of full explicit 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?

Even without annotations, the description discloses significant behavioral traits: the $0.005 USDC cost per call, x402 payment on Solana mainnet, and that it returns a quote for a swap (not an order execution). This is valuable beyond the schema, covering cost and network context, though it omits failure modes or rate limits.

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 with the core purpose front-loaded, followed by the cost detail. Every sentence adds new information, and there is no filler or 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?

The tool has simple parameters and the schema documents them well. The description covers the key outputs (output amount, price impact, route) and adds critical context (cost, network, executable price). It lacks a detailed return schema, but that is absent overall, so the description provides sufficient context for an agent to understand the tool's behavior.

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% parameter coverage with descriptions for amount, input_mint, and output_mint, including the 'raw base units' detail. The description adds minimal extra parameter meaning; it only clarifies that these are SPL tokens, which is a minor addition. Baseline 3 is appropriate given the schema's completeness.

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 'Live Jupiter swap quote for any SPL pair' with specific outputs (output amount, price impact, route). It also differentiates from sibling pricing tools by emphasizing 'The real executable price on Solana, not an index price', which distinguishes it from index-price utilities.

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?

Usage context is implied: the tool is for getting live swap quotes on Solana and is contrasted with index prices, suggesting it should be used when an executable price is needed. However, it does not explicitly name alternatives or provide when-not-to-use guidance, leaving the agent to infer the decision.

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 the full burden of disclosing behavior. It only states that the index has a classification, but does not explain the classification scheme, output format, or that this is a read-only operation. This is minimal and leaves the agent guessing about the response structure.

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, consisting of one informative sentence plus the word 'Free'. While 'Free' is arguably irrelevant to an AI agent's selection or invocation, the core is front-loaded and there is no excessive verbosity.

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 conveys the essential return value (index score and classification). However, it lacks interpretive context (e.g., what values mean, how often it updates) and does not differentiate from other sentiment tools in the sibling list, making it minimally adequate.

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 there is no schema information needing further explanation. The description clarifies that the tool provides a value and classification, which is sufficient given the absence of 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 identifies the resource as the Crypto Fear & Greed index, specifies its scale (0-100), and notes it includes classification. This distinguishes it from sibling tools like funding rates or long/short ratios, which measure different market sentiments.

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?

There is no guidance on when to use this tool versus alternatives. The description offers no context for choosing the Fear & Greed index over other sentiment metrics, and the mention of 'Free' does not convey selection criteria. This leaves the agent to infer usage solely from the name.

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 transparency burden. It discloses that the tool is free, returns machine-readable data, and provides self-settlement instructions, adding useful behavioral context beyond a simple statement of purpose. A minor gap is the lack of response format 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 short and front-loaded with 'FREE', but it repeats 'Free' at the end, which is mildly redundant. Still, it conveys all necessary information in just two sentences, earning a strong conciseness 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 has no parameters and no output schema, the description sufficiently specifies the returned content (question, settlement instructions, covered symbols) and the recommended usage sequence. The lack of machine-readable format details is a minor omission but does not undermine overall completeness for this simple 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 tool has zero parameters, so the schema is empty. The description clarifies what the tool does with no input, meeting the baseline for zero-parameter tools and providing enough context for an agent to understand the lack of 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 returns the exact forecast question in machine-readable form, plus settlement instructions and covered symbols. This uses a specific verb and resource, and it distinguishes itself from sibling tools like get_cascade_forecast that likely provide the forecast value itself.

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 phrase 'Read this before building on the forecast' gives explicit when-to-use guidance. However, it does not explicitly mention when not to use the tool or name alternatives, so it stops short of a full 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?

With no annotations, the description carries the full burden and does well: it discloses that forecasts were written down before the window opened, settled from a public feed, and that raw rows are returned for recomputation. It also marks the tool as 'FREE.' It omits rate limits or error details, but for a read-only data tool this is strong 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 mostly front-loaded with 'FREE' and the core purpose, and each sentence adds value. However, 'Free' is repeated at the end, and the backtest comparison is slightly verbose. Still, it remains appropriately sized 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?

No output schema exists, but the description enumerates the returned metrics and raw rows, covering the essential return structure. It also explains data provenance, making it contextually complete for a simple retrieval tool with two optional 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 coverage is 100% with clear descriptions for both parameters ('rows' and 'symbol'). The description adds that raw rows are returned, giving context to the 'rows' parameter, but otherwise relies on the schema. This meets the baseline for high 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 returns the live track record of a miner, with specific metrics listed (settled count, base rate, Brier skill, etc.), and contrasts it with a backtest. This distinguishes it from sibling forecasting tools and provides a concrete, specific purpose.

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 positions the tool as a trustworthy alternative to backtests, explicitly stating 'this is not that,' which tells users when to use it (when they want pre-committed, verifiable forecasts) and when not (for backtests). It doesn't name sibling tools but gives clear contextual 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?

Without annotations, the description takes on the burden of behavioral disclosure. It reveals the cost per call ($0.01 USDC via x402 on Solana mainnet) and that it executes a cross-venue query, but doesn't describe response format or potential failure modes. Still, it gives meaningful operational context.

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

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

Two sentences with high information density. Every clause adds value: scope, venues, spread/crowding, sibling limitation, and cost.

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 one-parameter read-only tool with no output schema, the description covers the essential invocation context: what it does, which venues, what extra metrics, and the cost. It could clarify the meaning of 'crowding read' or return structure, but it's 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 schema already describes the symbol parameter as a USDT perp symbol (100% coverage). The description reinforces that the parameter accepts any USDT perpetual and adds the cross-venue context, giving the agent a richer understanding of what values are acceptable.

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 returns funding rates for ANY USDT perp across Bybit, OKX, and Hyperliquid, and explicitly distinguishes it from get_funding_rate which covers SOL+BTC only. The verb 'get funding' plus the cross-venue scope makes 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?

It explicitly says get_funding_rate covers SOL+BTC only, directing users to use this tool for any other USDT perp. It also mentions the cost and payment rail, which helps decide when to use 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?

With no annotations, the description carries the full burden. It discloses cost ($0.02 USDC per call), network (Solana mainnet), scope (~600 USDT perps), and key output elements (annualized %, 24h price move, OI). It also provides interpretive context. It does not mention auth or failure modes, but for a simple read-only query this is adequate.

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 concise sentences carry substantive information: first describes what the tool returns, second adds cost and use case. No wasted words, and the most critical info is 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?

For a simple data-retrieval tool with no output schema, the description covers the essential context: data scope, output fields, cost, network, and practical interpretation. It is complete enough for an agent to decide when and how to use it.

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 schema already explains limit and min_turnover_usd well. The description adds no additional parameter-specific meaning beyond what the schema provides, so no credit beyond 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: returning the most-positive and most-negative funding rates across ~600 USDT perps, with annualized %, 24h price move, and OI. It uses a specific resource ('funding extremes') and distinguishes itself from siblings like get_funding_rate or get_funding_history by emphasizing 'crowded trades' and the top/bottom extremes.

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 a clear use case: identifying squeeze candidates via crowded shorts ('Crowded shorts = squeeze candidates'). It does not explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to select this tool for extreme-funding screening.

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 $0.005 USDC cost, x402 payment mechanism, Solana mainnet, and the 200-interval limit, which are critical operational details beyond typical tool descriptions.

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 front-loaded purpose and a concise cost note. Every word contributes meaning, and there is no redundant or vague filler.

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 two parameters and no output schema, the description provides sufficient context: core function, cost, and computed metrics. It omits response structure but that is acceptable for a simple statistics-returning tool.

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

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

Schema coverage is 100% for both parameters, so the schema already documents symbol and limit. The description adds minimal context such as 'up to 200 intervals' but does not materially enhance understanding of how limit affects output 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?

Description clearly identifies the tool as returning funding-rate history for any USDT perp, with specific metrics (average, annualized, share of positive intervals), distinguishing it from siblings like get_funding_rate or get_funding_extremes by focusing on historical carry.

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 assessing historical carry on USDT perps but does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions. Guidance remains implicit rather than direct.

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 a critical behavioral trait: the tool costs $0.002 USDC per call via x402 on Solana mainnet. It also states the data source (Hyperliquid). While it does not detail output format or error handling, the cost and source are valuable 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 two concise sentences, front-loaded with the core purpose and followed by a critical operational detail (cost). Every word earns its place; there is no redundancy or filler.

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 read-only tool with no parameters and no output schema, the description is sufficiently complete. It covers what data is returned, the asset scope, the exchange, and the cost. No additional context is necessary.

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 the baseline is 4. The description adds meaning by explaining what data is returned (funding rates, mark prices, open interest), which is useful beyond the empty schema. No further parameter-specific explanation 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 identifies what the tool returns: current SOL and BTC perp funding rates, mark prices, and open interest on Hyperliquid. It uses specific resource names and distinguishes it from sibling tools like get_funding_cross or get_funding_history by specifying assets and exchange.

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 retrieving current SOL/BTC funding data, but it does not explicitly state when to use this tool versus alternatives (e.g., get_funding_cross for more assets, get_funding_extremes for historical extremes). No exclusions or alternative 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?

With no annotations, the description carries the full burden. It discloses the cost per call ($0.005 USDC), network (Solana mainnet), and the data scope (p25-p99 percentiles, recommendation), which is valuable behavioral context beyond the tool name.

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 two sentences are efficient and front-loaded with the core value proposition, followed by cost information. No redundant text or filler.

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 no-parameter data tool with no output schema, the description adequately conveys the nature of the data (percentiles, recommendation) and operational details (cost, network). It could mention return format, but given simplicity, it is sufficient.

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 schema is trivially 100% covered. The baseline for 0 params is 4, and the description appropriately focuses on the output rather than inputs, which is correct given 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 specifically defines the resource ('Jito bundle tip floor percentiles (p25-p99, SOL)') and what it represents ('what landed bundles are actually paying, with a landing recommendation'), which clearly differentiates it from sibling tools like get_priority_fees or get_sol_price.

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 getting current tip level recommendations ('with a landing recommendation') and provides context for when to call, but does not explicitly name alternatives or exclusions. The cost note also informs usage decisions.

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 the full burden. It discloses the 15-minute delay, limited asset coverage, and free status. It does not describe the return format or any rate limits, but for a simple 'taster' the disclosed traits are relevant and helpful.

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 and front-loaded with the key information. However, 'Free' appears twice, and the final 'Free.' is redundant, slightly reducing efficiency.

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 the essential context: purpose, scope, delay, and alternative. The absence of an output schema and annotations makes some ambiguity about the exact return value, but for a 0-parameter free sample tool, 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 zero parameters, so the schema is fully covered. The baseline of 4 applies, and the description adds context about the data scope rather than parameter details, which 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 returns the last liquidation for a specific set of assets (SOL, BTC, ETH, XRP, DOGE) with a 15-minute delay. It uses a specific verb+resource pattern and differentiates from the sibling get_recent_liquidations by explicitly noting the real-time alternative.

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 usage guidance by positioning itself as a free taster and directing users to get_recent_liquidations for real-time needs. This clearly tells the agent when to use this tool versus the alternative.

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 the full burden of disclosing behavioral traits. It discloses the data source ('our own tape'), authenticity ('Real prints'), the cost ($0.05 USDC per call), and output features (long/short split, hottest zone). It does not mention rate limits or error behavior, but provides strong context beyond the schema.

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, front-loaded with the purpose, and contains no filler. Every phrase adds value, from data source to output details to cost, achieving maximum 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?

In the absence of an output schema, the description explains the key output components ('USD, prints, long/short split per price zone, hottest zone flagged') and provides cost context. It lacks edge-case handling or formatting details, but for a simple 3-parameter tool, it is sufficiently 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 descriptions for hours, symbol, and buckets. The description references 'last N hours' and 'per price zone,' which align with the schema, but it adds no new parameter-specific details 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 provides a liquidation heatmap by price level, with specific details on output ('USD, prints, long/short split per price zone, hottest zone flagged'). It distinguishes itself from other liquidation tools by emphasizing 'Real prints, not entry-price estimates,' making the purpose specific and unique.

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 appropriate usage (when you need actual liquidation flush data by price level) and includes practical guidance such as the cost. However, it does not explicitly name alternative tools or state 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?

With no annotations, the description carries the transparency burden. It discloses the cost ($0.05 USDC per call), the data source (Bybit), the lookback period (up to 7 days), and data uniqueness ('no exchange publishes history of it'). It does not mention auth requirements, rate limits, or error handling, but the disclosed traits are significant beyond the schema.

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 consists of two efficient sentences. The first sentence front-loads the core functionality and output fields, the second adds unique value and pricing. No fluff, every clause 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 no output schema, the description compensates by listing the return categories (total/long/short USD, prints, biggest print). It covers scope, time range, and cost. It is missing details on output format, authentication, or error conditions, but for a single-purpose data tool with rich param context, it 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 schema already covers 100% of parameters, so the baseline is 3. The description adds meaning by explaining the output structure ('total/long/short USD, prints, biggest print per bucket') which clarifies the impact of bucket_min, and 'up to 7 days back' reinforces the hours parameter. It also clarifies scope with 'Any USDT perp or the whole ~600-perp universe.' This goes beyond the schema's basic 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 the tool's function: 'HISTORICAL liquidation tape, time-bucketed: total/long/short USD, prints, biggest print per bucket.' It specifies the resource (liquidation tape), the verb (get historical), and distinguishes from siblings by emphasizing historical depth and time-bucketing. The mention of 'any USDT perp or the whole ~600-perp universe' further clarifies scope.

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 strong contextual guidance by stating 'this data exists nowhere else' and 'Bybit is the only complete liq tape in crypto,' implying this is the go-to tool for historical liquidation data. It also mentions the cost, aiding decision-making. However, it does not explicitly name alternative tools or state when not to use this tool, falling 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?

No annotations exist, so the description carries the full burden. It discloses the cost ('$0.02 USDC per call (x402, Solana mainnet)'), the exact data scope (~600 USDT perps across three venues), and the per-symbol output fields. This is substantial transparency, though it omits potential edge cases like zero-liquidation responses or data latency.

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?

Each sentence earns its place: the first defines the core ranking, the second enumerates returned metrics, the third positions its role, and the fourth states the cost. No fluff.

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

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

Despite having no output schema, the description enumerates the key fields per symbol (total liquidated, long vs short split, biggest single print, venue count, dominant side), giving the agent a clear mental model. Cost and venue scope are also covered. It could add information about response format or error behavior, but overall it is quite complete for a two-parameter list 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%: limit and window_min both have descriptions with ranges and defaults. The tool description does not add any parameter-specific semantic beyond what the schema provides, so 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 clearly identifies the tool as a real-time liquidation leaderboard: 'top symbols ranked by liquidation USD across ~600 USDT perps on Bybit, OKX and Binance.' It specifies unique output fields (long vs short split, biggest single print, venue count, dominant side) and distinguishes itself as 'the fastest read on where leverage is being flushed,' setting it apart from historical tools like get_liq_history.

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 conveys the tool's niche: real-time liquidation spotlights with 'RIGHT NOW' and 'fastest read,' implying it should be used for immediate leverage-flush monitoring. However, it does not explicitly name alternatives or provide when-not-to-use guidance, leaving a minor gap.

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 the cost ($0.004 USDC per call) and network (x402, Solana mainnet), which is behavioral trait information. It does not explicitly state read-only or side effects, but the nature of a stats call implies a read operation. The per-exchange breakdown hint also clarifies expected output structure.

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 long, immediately stating what the tool returns and then the cost. Every sentence adds value, with no filler or repetition. The key facts (assets, metrics, breakdown, cost) are 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?

The tool has no parameters and no output schema, so the description must completely explain the tool's output and constraints. It lists the exact assets, timeframes, metrics, exchange breakdown, and cost, making it fully self-contained for a zero-parameter 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?

This tool has zero parameters, so the description need not explain parameter semantics. The baseline for 0 parameters is 4, and the description adds useful context about the scope (5 majors) and cost, even though these are not 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 what the tool does: provides liquidation aggregates for 5 specific majors (SOL, BTC, ETH, XRP, DOGE) with details like 1h/24h totals, longs vs shorts split, biggest print, and per-exchange breakdown. This distinguishes it from sibling tools like get_last_liquidation or get_recent_liquidations, which focus on individual liquidations or recent events.

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: it is for getting aggregate liquidation stats across 5 majors, rather than individual or historical liquidations. However, it does not explicitly state when to use it over alternatives or when not to use it, so it lacks explicit exclusions or alternative comparisons.

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 must carry the burden. It does disclose a cost of $0.01 USDC per call and the x402/Solana mainnet network, which is useful. However, it doesn't explicitly mention that this is a read-only operation or describe any other behavioral constraints beyond the cost.

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, front-loaded with the core function and followed by a critical cost note. It contains no filler or redundant information, making it very concise 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?

For a simple one-parameter tool with no output schema, the description conveys the key outputs (ratio with 1h and 24h trends) and the cost, which is important. It doesn't detail exact return fields, but the core context is sufficiently covered for an agent to decide to invoke it.

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 a 100% coverage of the single parameter 'symbol' with a clear description ('USDT perp symbol e.g. SOLUSDT'). The tool description's mention of 'ANY USDT perp' adds a slight emphasis but doesn't provide additional semantic detail beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states it provides the long/short account ratio for any USDT perp, including trend information and a labeling as a retail crowding gauge. This is a specific resource and metric, distinguishing it from sibling tools like funding 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 phrase 'retail crowding gauge' implies a use case for sentiment analysis, but there is no explicit comparison to alternatives or exclusion of when not to use it. The context is clear, but no direct guidance 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?

No annotations are present, so the description carries the full burden. It discloses a per-call cost of $0.003 USDC and the x402 payment mechanism on Solana mainnet, which is critical behavioral information for a paid API. It does not mention other potential behaviors like rate limits or failure modes, but for a simple read-only snapshot, this is sufficient.

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 short sentences, front-loaded with the tool's purpose followed by the cost. Every word 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 zero parameters and no output schema, the description is fairly complete: it lists the data types included and the cost. However, it does not elaborate on the response structure or any prerequisites beyond the payment method, which could leave an agent slightly under-informed.

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 the schema is trivially complete. The description adds no parameter-specific meaning because none exist. Per the baseline for 0 params, a score 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 SOL+BTC prices, funding rates, and Fear & Greed in a single call. This specific verb and resource list distinguishes it from individual data sibling tools like get_btc_price or get_funding_rate.

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 phrase 'in one call' implies this is an aggregation tool for combining multiple data points, but it does not explicitly discuss when to use this vs individual endpoints or any exclusions. No alternatives are named.

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 transparency burden. It discloses scope (~600 perps), baseline window (30min+), included context (funding and price), and per-call cost ($0.02 USDC via x402 on Solana). This goes well beyond a minimal description, although it does not explicitly state output format or failure/edge-case 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?

Two dense sentences deliver the core purpose, what it measures, why it matters, and the cost. Every phrase earns its place; no filler. The front-loaded 'Abnormal open-interest jumps' immediately clarifies the tool's function.

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 single-parameter scanner with no output schema, the description covers the what, how, scope, and cost. The main gap is that it does not describe the return format (likely a list of perps with metrics), which would be helpful since no output schema exists. Still, the description is robust enough 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?

Schema coverage is 100% for the single parameter 'limit' which is described as 'top N, 1-25, default 10'. The description adds no extra parameter details, but the schema is sufficient, so this meets the high-coverage 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 specifies a unique verb+resource combination: detects abnormal open-interest jumps across ~600 USDT perps compared to a 30min+ baseline. It also explains what the scan reveals (new leverage piling in) and its purpose (squeeze/flush precursor screener), distinguishing it from sibling tools like get_open_interest or get_funding_rate.

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 when to use this tool (when looking for OI spikes as squeeze/flush precursors) but provides no explicit comparison or exclusions relative to sibling tools. It does not name alternatives like get_squeeze_score or get_cascade_scan, leaving the user to infer the tool's unique niche. The cost and x402 payment detail adds operational context but not tool-selection 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?

No annotations are provided, so the description carries the burden. It discloses the per-call cost ($0.01 USDC), the payment mechanism (x402), and the specific data content (Bybit OI, OKX OI, changes). This is valuable behavioral context, though it omits details like 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?

Two sentences, front-loaded with the core purpose, followed by a sibling distinction and cost note. Every word earns its place with no 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?

For a single-parameter data retrieval tool with no output schema, the description is fairly complete: it specifies data sources, metrics, cost, and the relationship to a sibling tool. It doesn't describe the exact return structure, but that is not critical for basic usage.

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 a clear example ('e.g. SOLUSDT'). The description adds minimal extra meaning beyond emphasizing 'ANY' symbol, which is marginal. Baseline 3 is appropriate since the schema already documents the parameter well.

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 open interest for any USDT perpetual, specifying sources (Bybit, OKX) and metrics (base/USD, 1h/24h change). It distinguishes itself from sibling get_positioning by noting that tool covers only SOL+BTC.

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 explicitly contrasts with get_positioning ('covers SOL+BTC only'), indicating this tool is the broader alternative. It also discloses the cost per call, helping the agent decide when to use 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?

With no annotations, the description bears full responsibility for disclosing behavioral traits. It effectively discloses the cost ($0.01 USDC), payment network (x402/Solana mainnet), and output composition (USD each side, ratio, skew). Missing are details about latency, errors, or data freshness, but the cost and network are valuable beyond what schema provides.

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, front-loaded with the core purpose and followed by cost/network. Every word earns its place, and there is no redundant content or repetition of schema details.

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 2-parameter schema and no output schema, the description conveys the main function, scope, and cost. However, it does not fully specify the return structure (e.g., exact fields, units, or precision) which would be needed for a complete picture in the absence of an output schema. That gap prevents a higher score.

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%: both 'symbol' and 'bps' have descriptions. The description adds minimal semantics beyond the schema, merely restating the bps window concept. It does not further elaborate on parameter formats, ranges, or interactions, so a 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 states a specific function: computing bid/ask resting-liquidity imbalance within a bps window around mid for any USDT perp. It names the return components (USD each side, ratio, skew), making it distinct from sibling tools like get_orderbook_walls or get_basis.

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 clearly scopes usage to USDT perps and defines the bps window, giving context for when to apply this tool. It also notes a per-call cost, adding a practical usage consideration. However, it does not explicitly mention alternatives or when not to use it, so it stops 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?

With no annotations provided, the description carries the full burden and does well by disclosing the cost ($0.01 USDC per call) and the payment network (x402, Solana mainnet). This adds meaningful behavioral context beyond the basic function, though it could mention rate limits 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 a single, well-structured sentence that front-loads the core purpose and then adds cost/network information. Every word earns its place with no 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 output schema, the description adequately describes the returned data (largest orders, USD size, distance from mid) and includes cost context. It lacks explicit coverage of edge cases or data sources, but for a simple order book tool it is sufficiently 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 description coverage is 100%, so the schema fully documents both parameters. The description adds no parameter-specific details beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool's output: largest resting orders (walls) per side of the order book, with USD size and distance from mid, specifically for USDT perps. It distinguishes itself from the sibling get_orderbook_imbalance by focusing on walls rather than imbalance.

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 when one needs order book wall data for USDT perps, but it does not explicitly state when to use this tool over alternatives like get_orderbook_imbalance. It provides context (any USDT perp) but no exclusions or comparisons.

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 bears full burden. It discloses the tool is read-only, has a cost, samples every 5 minutes, and uses a unique collector. It does not mention rate limits or error handling, but the cost and uniqueness are well stated.

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 three sentences, front-loading the core purpose and then adding unique context (data source, cost). Every sentence adds necessary information without fluff.

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

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

For a paid tool with 2 parameters and no output schema, the description covers purpose, data source, cost, sampling, and time split. It lacks explanation of return value structure, which would be helpful, but overall it is sufficiently 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%, so baseline is 3. The description adds value by providing example symbol formats (CRCLx, MSTRx, COINx) and implying the hours parameter via '24h stats', though it doesn't detail the range. The examples enhance understanding.

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

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

The description clearly states the tool returns peg deviation for tokenized US equities on Solana, specifying it measures on-chain DEX price vs underlying trade in bps with 24h stats split by market-open and off-hours. This distinguishes it from siblings like get_basis or get_spread_arb.

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 context on data uniqueness and cost ($0.02 USDC per call), implying it's a premium data tool. However, it does not explicitly state when to use vs alternatives or when not to use 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?

No annotations are provided, so the description carries full burden. It discloses cost ($0.03 USDC) and mentions flagged worst off-hours window and market-open control, but does not discuss idempotency, permissions, or side effects. Adequate but minimal.

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 key information front-loaded: purpose, metrics, cost. No redundant words, efficiently 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 no output schema, the description adequately hints at return structure (mean, p95, max bps, median liquidity per session, flagged worst window). Missing pagination or more detailed output format, but sufficient for 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?

Schema coverage is 100% (both parameters described). The description adds no additional meaning beyond the schema's descriptions for 'days' and 'symbol'; it does not elaborate on parameter usage or constraints.

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 breaks out peg deviation by trading session and lists metrics: mean, p95, max bps, median liquidity. It also mentions control and flagging of worst off-hours window, clearly differentiating from sibling tools like get_peg_deviation.

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 does not explicitly state when to use this tool versus alternatives. While the cost and session breakdown imply usage for detailed session analysis, no when-not-to-use or alternative 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?

With no annotations, the description carries the full burden. It discloses the cost ($0.05 USDC per call) and the exclusion of dead pools, which are important behavioral traits. However, it does not mention idempotency, rate limits, or whether sorting order is stable.

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 and front-loaded with the core purpose. Every sentence adds value, and there is no redundant 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?

Despite no output schema, the description adequately explains the return structure (ranked list with specific fields) and adds context about cost and dead pool exclusion. It is complete for an agent to understand what to expect.

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

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

Schema description coverage is 100% for both parameters (days and min_liquidity_usd). The description does not add additional meaning beyond what the schema already provides, so baseline score 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 returns a ranked list of tokenized US equities with specific metrics (off-hours peg risk, p95, max deviation bps, etc.). It distinguishes itself from other peg-related tools like get_peg_deviation by focusing on a universe ranking.

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 does not explicitly state when to use this tool over alternatives. While the purpose is clear, there is no guidance on scenarios where it is preferred or when other tools (e.g., get_peg_deviation) might be more appropriate.

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

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

The description discloses the cost ($0.004 USDC per call) and payment mechanism (x402), plus the data source (Bybit), which adds meaningful context beyond the absent annotations. However, it does not mention read-only nature, rate limits, or any side effects, so it is only moderately transparent.

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, front-loaded with the core data content followed by the cost. Every word earns its place, with no redundancy or filler.

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 no-parameter data fetch, the description adequately enumerates the returned data points (long/short ratio, OI changes) and specifies the venue and cost, effectively serving as an implicit output description. It lacks an explicit return format, but given no output schema, this is reasonably complete for an agent to predict behavior.

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 the description does not need to explain parameter syntax. The schema is empty and the description lists the data content, aligning with the baseline of 4 for no-parameter tools.

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 returns SOL+BTC positioning data including long/short account ratio and open interest with 1h/24h change on Bybit. It is specific about content and venue, but does not explicitly differentiate from sibling tools like get_long_short or get_open_interest, which may cover overlapping 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 given on when to use this tool versus alternatives such as get_long_short or get_open_interest. The cost note could influence selection, but there are no explicit exclusions or contextual triggers, leaving the agent to infer 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?

With no annotations provided, the description takes full responsibility for behavioral disclosure. It reveals the fee ($0.005 USDC per call), payment mechanism (x402), network (Solana mainnet), and that the value is an estimate, not a guarantee. It also explains the output format comprehensively, which is critical for a tool with no output schema.

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?

Three concise, information-dense sentences. The opening sentence front-loads the core purpose and output details. The second sentence gives the use case, and the third covers cost and network. No redundancy or filler.

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 remarkably complete. It tells the agent what data to expect (all levels, units, recommended tip) and the operational conditions (cost, network, target audience). It is sufficient for an agent to invoke and interpret the result confidently.

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 the schema already covers all inputs (trivially). The description adds meaning by explaining what the output means (micro-lamports/CU, levels, recommended tip), which compensates for the lack of output schema. Baseline for 0 params is 4, and the description meets 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 specifies the resource (Solana priority fees), the action (estimate), and the time frame (right now). It details the output levels (min to unsafeMax) and units (micro-lamports/CU), clearly distinguishing it from similar fee-related tools like get_jito_tips.

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 the target use case: 'For bots that need txs to land.' It also adds cost and network context. While it doesn't name alternatives or exclusion scenarios, the use case is specific enough for an agent to decide when to choose 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?

With no annotations provided, the description carries the full transparency burden. It discloses the cost ($0.003 USDC per call), the exchanges covered, and that it provides a complete unthrottled tape, which are important behavioral traits. However, it omits details like data latency, sorting, or time window, though these are partially inferable from the schema.

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 with no fluff. The first sentence states the core function and output fields; the second adds scope and cost. It is appropriately sized, front-loaded, and every phrase adds value.

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 has moderate complexity with 4 optional parameters and no output schema. The description covers the main output content, exchanges, symbol scope, and pricing. It does not mention sorting order or time window, but the term 'recent' and schema defaults provide some context. Overall, it is nearly complete for the tool's purpose.

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% coverage with descriptive parameter explanations, so the baseline is 3. The description adds minimal extra parameter meaning, only reinforcing the broad symbol coverage (e.g., 'any USDT perp') which complements the symbol parameter. It does not significantly improve understanding of limit, scope, or min_usd 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?

The description clearly states the tool fetches recent perp liquidations across Bybit, OKX, and Binance, with specific output fields (timestamp, long/short, size, price, USD value). It differentiates itself from siblings by emphasizing 'complete unthrottled tape' and broad symbol coverage (~600 USDT perps), making its unique value 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?

The description provides clear context for when to use the tool: for comprehensive multi-exchange liquidation data, not limited to major symbols. It mentions the cost, which is a key usage consideration, but does not explicitly name alternative tools or state when not to use it, hence a slight deduction.

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 the full burden and does well: it discloses cost ($0.02 USDC per call), threshold statistics (p99.9, median), and returned fields (match, competition, minutes to kickoff, probability path, move size, direction, severity). It could add explicit read-only status or side-effect notes, but the behavioral context is strong.

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 dense paragraph but every sentence earns its place, covering purpose, statistics, outputs, and cost. It is somewhat long but highly informative; a clearer structure (bullets) would improve it, but it remains efficient and front-loaded with intent.

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 fully covers what the tool does, when to use it, what it returns, and its cost, without relying on an output schema. It explains the statistical basis and severity levels, making the tool self-contained for an AI agent 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 schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds real meaning by explaining the default threshold (2.81 percentage points per 5 minutes) in the context of its p99.9 derivation and normal move sizes, which helps the agent understand the parameter's significance 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 opens with 'SHARP MONEY DETECTOR for World Cup betting markets' and specifies it 'Finds abnormal PRE-MATCH moves in the de-margined consensus win probability', clearly identifying the verb, resource, and scope. It is distinct from the many crypto-focused sibling tools, making its purpose immediately obvious.

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 states 'Use before placing or pricing a World Cup bet, or to detect informed money entering a market', giving explicit use cases. It also explains why pre-match detection matters ('because no match is in play, there is nothing to react to'). However, it does not explicitly name alternatives or when-not-to-use scenarios, so it stops short of a full 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the $0.005 cost per call and x402 payment method, which is valuable. However, it doesn't explicitly state read-only behavior, rate limits, or error conditions, leaving some transparency gaps.

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, front-loaded with the core purpose, followed by cost. Every sentence adds value and there is no filler.

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 output schema, the description sufficiently lists the key returned metrics (TPS, slot, epoch progress), giving a good sense of the response. It doesn't specify the structure or error handling, but for a no-parameter getter, it is mostly 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 zero parameters, so there is no parameter information to document. The description doesn't need to compensate, and the baseline for 0 parameters is a 4.

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

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

The description clearly states the tool retrieves Solana network health metrics (TPS, slot, epoch, epoch progress). The verb 'get' and resource 'Solana network' are specific, and it distinguishes itself from sibling market/price tools by listing unique data points.

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 intended use is implied by 'Solana network health' but there is no explicit when-to-use or alternatives among the many sibling get_* tools. It doesn't state when to prefer this over other network-specific tools, but the context is clear enough for a straightforward health check.

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 the full burden and does well: it discloses the live nature, confidence interval, Pyth oracle source, and a per-call cost of $0.001 USDC via x402 on Solana mainnet. It doesn't describe return format or error cases, but these are less critical for a simple price query.

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: the first front-loads the purpose, the second adds cost and execution context. No superfluous words or repetition of schema.

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 no-parameter, no-annotations tool, the description covers the essential aspects: what is returned, the source, and the cost. Lacks explicit return format details, but the tool's simplicity and clear description make it adequately 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?

There are zero parameters, so the baseline is 4. The description adds meaning by clarifying the output (SOL/USD spot price with confidence interval), which is valuable given no output 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 explicitly states it returns the live SOL/USD spot price, with a specific resource (SOL/USD) and a clear data source (Pyth oracle). This differentiates it from sibling price tools like get_btc_price.

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?

Usage context is implied: this is the tool to use for SOL/USD price. However, it does not explicitly mention alternatives or when not to use it, leaving the guidance implicit.

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 the burden and does well by disclosing a per-call cost ($0.02 USDC), the payment/network context (x402, Solana mainnet), and that the edge is pre-fee. It does not mention return format or failure modes, but the key behavioral aspect (paid call) is clearly disclosed.

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 that conveys purpose, venues, metric, fee basis, and cost with no redundant words. It is 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?

For a simple one-parameter tool with no output schema, the description is largely complete: it explains what is returned, the venue scope, the fee basis, and the cost. It could slightly improve by mentioning expected output shape or data freshness, but these are not critical for basic 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 input schema has 100% coverage for the single 'symbol' parameter, including an example ('SOLUSDT'). The description adds no additional parameter meaning beyond the schema, so the 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 uses a specific verb ('get') and resource ('spread arb'), and clearly states the scope: best bid/ask for a USDT perp across Bybit, OKX and Hyperliquid, plus best cross-venue edge in bps. This differentiates it from sibling tools like get_basis or get_orderbook_imbalance.

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 by describing what data it returns, but it never explicitly states when to use this tool versus alternatives such as pricing or get_orderbook_imbalance. No exclusions or alternative recommendations are 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 present, so the description carries full burden. It discloses the computation inputs (funding, crowding, OI build, liq-skew), the output range (0-100), the meaning ('is this trade crowded and about to hurt someone'), and a per-call cost with payment network (x402, Solana mainnet). It stops short of describing error behavior or exact response format, but the core behavior is well covered.

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?

Three sentences, each with clear value: the headline purpose, the composite factors, and the cost/payment info. Front-loaded with 'FLAGSHIP' and the score definition. No filler or repetition of schema details.

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 simple (one parameter, no output schema), and the description covers the score's range, construction, and business meaning, plus cost. It doesn't explicitly state the return format, but 'One number' implies a scalar response. The lack of details on error conditions or symbol validation is a minor gap, not critical for such a straightforward 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% for the single 'symbol' parameter, so the schema already specifies the format ('USDT perp symbol e.g. SOLUSDT'). The description reinforces this with 'any USDT perp' but adds no new meaning 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?

The description clearly states it computes a short-squeeze/long-flush score from 0-100 for any USDT perp. It uses specific verbs ('answers') and resource ('any USDT perp'), and differentiates itself from sibling tools by being a composite metric ('Composite of funding, long/short crowding, 24h OI build, and liq-skew').

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 gives context (use it to assess crowding/risk for any USDT perp) and calls it 'FLAGSHIP', implying it's the primary sentinel. However, it does not explicitly state when to use this over alternatives like get_funding_extremes or get_positioning, nor does it mention exclusions. The cost note provides practical usage guidance but not comparative 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?

With no annotations, the description carries the full behavioral burden. It uniquely discloses the cost ($0.01 USDC per call) and network (x402, Solana mainnet), which are important operational details. It implicitly indicates a read-only query via 'get', but does not describe output format or error 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 two sentences, front-loaded with the core function and followed by cost/network details. Every word adds value with no filler or 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 has no parameters and no output schema, the description sufficiently explains what the tool returns (total supply, deltas, top stables) and the crucial operational constraint (cost). It is complete for a simple 0-parameter 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 tool has zero parameters, so the schema is vacuous. Per the rubric, the baseline for 0 parameters is 4. The description offers no parameter details, but none are 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 identifies the tool's output: total stablecoin supply with 7d/30d deltas and top stables. It also adds the context of being a macro risk-on/risk-off dial, which differentiates it from sibling tools that focus on other metrics like basis, funding, 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 provides a clear usage context ('the macro risk-on/risk-off dial for crypto'), indicating when this tool is relevant for gauging market sentiment. However, it does not mention any alternatives or exclusions, so it stops short of explicit when-not-to-use 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?

With no annotations, the description carries the full burden. It discloses cost, network (Solana mainnet), and the granularity of data returned (per-account share, concentration). While it doesn't explicitly state the operation is read-only, the getter nature is implied. The cost disclosure adds behavioral transparency beyond the name.

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 three concise sentences. Each sentence adds value: the first defines the output, the second differentiates from a sibling, the third provides cost and network context. No filler or redundancy, and the key information is 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?

For a single-parameter, no-output-schema tool, the description provides sufficient context: purpose, data details, cost, and differentiation from a sibling. It doesn't detail the return format beyond what is mentioned, but the essentials are covered. A minor gap is the lack of explicit mention of any edge cases or limitations.

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 covers 100% of the single parameter (mint) with its description. The description adds no additional parameter-specific meaning beyond stating 'any SPL token', which is already implied by the schema. Thus, the schema does the heavy lifting, warranting 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: retrieving top holders of any SPL token with per-account share and top1/top5/top10 concentration. It also distinguishes itself from sibling tool get_token_risk by offering a 'deeper cut' than its summary. This meets the requirement of a specific verb+resource+scope.

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 explicitly names an alternative (get_token_risk) and explains when this tool is more appropriate ('deeper cut than summary'). It also provides a cost consideration ($0.02 USDC per call) that helps decide usage. This is clear context for when to use versus 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?

With no annotations, the description discloses key behavioral traits: a per-call cost of $0.005 USDC, payment via x402, and Solana mainnet usage. This provides useful transparency beyond the schema, though it does not mention potential errors or rate limits.

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 concise sentences: the first defines purpose and outputs, the second provides cost and network details. Every word adds value with no 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?

For a simple one-parameter tool, the description lists the returned fields (name, symbol, decimals, supply, price) and the cost, which covers the essentials. It does not describe response format or error behavior, but given the low complexity and no output schema, it is sufficiently 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 schema provides 100% coverage for the single parameter 'mint' with a clear description. The tool description adds context about metadata fields but does not enhance parameter semantics beyond what the schema already offers.

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

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

The description explicitly states the tool retrieves SPL token metadata (name, symbol, decimals, supply, price) via Helius DAS, which clearly distinguishes it from sibling tools like get_token_holders or get_token_risk. The verb is implied but the resource and output fields are specific.

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 when a user needs SPL token metadata and notes the cost and network, but it does not explicitly compare with alternatives or state when not to use it. No sibling differentiation 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, the description carries the full burden and does well: it discloses the cost ($0.01 USDC), the execution network (Solana mainnet), the payment protocol (x402), and an interpretive hint ('revoked = safer'). It also explicitly states what the tool does NOT cover (honeypot/LP-lock), which is valuable behavioral context. It could mention expected return format or rate limits, but this is sufficient for a straightforward get 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 compact and front-loaded: the main purpose is stated first, followed by an exclusion, then cost/network details. Every sentence carries essential information with no filler. This is an exemplar of concise yet informative tool documentation.

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 single-parameter tool with no output schema and no annotations, this description is nearly complete: it explains what the tool returns, what it excludes, and key operational details (cost, network). The only minor gap is the vague term 'risk flags'—it doesn't enumerate what flags might appear. Still, given the low complexity, it covers the essential context effectively.

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

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

The input schema already describes 'mint' as 'SPL token mint address (base58)' with 100% coverage, so the baseline is 3. The description adds context by framing the mint in terms of rug-risk analysis, but it does not introduce new parameter semantics or format details beyond what the schema provides. The single parameter is adequately covered by the schema 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 opens with 'SPL token rug-risk signals', a specific verb+resource phrase that immediately conveys the tool's function. It then enumerates three concrete outputs (mint/freeze authority status, holder concentration, risk flags), distinguishing it from sibling get_* tools. The explicit exclusion 'Not a honeypot/LP-lock checker' further differentiates it from related risk-checking 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 context for when to use the tool: for rug-risk assessment of SPL tokens. It also gives a when-not scenario ('Not a honeypot/LP-lock checker') and mentions the cost/network ('$0.01 USDC per call (x402, Solana mainnet)'), implying this tool is for paid, mainnet-specific checks. However, it does not name any alternative tools explicitly, 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?

No annotations are provided, so the description carries the full burden. It adds valuable behavioral context: cost per call ('Costs $0.01 USDC per call'), the network (x402, Solana mainnet), and that movers come with 'funding attached.' It does not state read-only explicitly, but the nature of a screener implies a query with no side effects, and the cost disclosure is a meaningful addition.

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, front-loaded with the main purpose, followed by the cost and network detail. Every clause adds useful information: scope (24h, ~600 perps), the liquidity filter, the funding attachment, and the pricing. No filler or 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?

This is a low-complexity tool with two optional parameters fully documented in the schema. The description covers what the tool returns (gainers/losers with funding), the universe, and cost. No output schema exists, but the description sufficiently hints at the output fields. It is complete enough for an agent to confidently invoke it.

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% — both parameters (limit and min_turnover_usd) have clear descriptions in the schema. The tool description adds a bit of context by mentioning 'liquidity floor' which maps to min_turnover_usd, but overall it does not significantly enhance 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 purpose: '24h top gainers and losers across ~600 USDT perps with a liquidity floor, funding attached.' The verb 'get' plus the specific resource ('top movers') and the qualifier 'The what moved screener' make it unmistakable what this does and how it differs from sibling tools like funding or basis snapshots.

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 phrase 'The what moved screener' provides clear context for when to use this tool (when you want to see top 24h price movers). However, it does not explicitly mention when not to use it or name alternatives. Still, the context is strong enough to guide selection among many sibling getters.

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 the full burden. It discloses cost ($0.01 USDC) and execution layer (x402, Solana mainnet), which are valuable behavioral traits. However, it does not mention whether data is real-time, cached, rate-limited, or what happens on failure, leaving some transparency gaps.

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 concise sentences: first enumerates included data, second gives cost and network. Every word earns its place, no redundancy, front-loaded with the value proposition.

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 lists all included data components, giving a clear idea of the return contents. There is no output schema, so the listing serves as the output contract. It could be slightly more explicit about response format, but for a zero-parameter aggregation tool, it is adequately 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 zero parameters, so schema coverage is trivially 100%. The baseline for 0-param tools is 4, and the description appropriately focuses on output rather than inputs. No additional parameter explanation 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 identifies the tool as a one-call aggregate market state provider, listing specific data points (SOL/BTC prices, funding, fear/greed, positioning, open interest, liquidations). This distinguishes it from granular sibling tools like get_btc_price or get_funding_rate.

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 phrase 'complete pre-trade picture' provides clear use-case context, implying this is the go-to snapshot tool before trading. It does not explicitly say 'use instead of individual tools' but the contrast with siblings is obvious. Lacks explicit when-not-to-use 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?

With no annotations, the description carries the full burden. It discloses key behavioral traits: data source (DefiLlama-backed), cost ($0.005 USDC per call), network (Solana mainnet), and output content (1d/7d change). It falls short of specifying return format or error handling, but for this simple read-only tool the provided context is valuable.

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 concise, front-loaded with the primary purpose, and includes essential context in three short sentences. Every sentence earns its place with 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?

The tool is simple with one optional parameter and no output schema. The description covers purpose, data source, cost, network, and output content (changes/ranking). It lacks an explicit return type format, but this is adequately inferable from the description for such a straightforward tool.

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

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

The input schema already describes the 'target' parameter with examples and the omit-for-chains behavior (100% coverage). The description adds no further parameter-level semantics beyond the overall purpose, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: fetching TVL for a DeFi protocol or top-15 chains ranking, with 1d/7d change. It is specific and distinguishes itself from sibling tools that focus on prices, funding, 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?

Usage context is implied: if you need TVL data, use this tool. The description gives two modes (specific protocol or top chains) but does not explicitly mention alternatives or when not to use it relative to 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 burden. It discloses a key behavioral trait: the $0.02 USDC cost via x402 on Solana mainnet. However, it does not mention return format, data freshness, or error behavior, which are significant gaps for a paid 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?

Two sentences with zero fluff. The primary purpose is front-loaded, and the cost note is a separate concise sentence. Every word 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?

The description covers the core functionality and payment cost, but there is no output schema and the description does not describe the return structure. For a paid tool, the agent would benefit from knowing what fields to expect (e.g., share percentages, long/short values). It is adequate but has clear gaps.

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

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

Schema coverage is 100%, so parameters are already documented with descriptions and defaults. The description adds contextual value by naming the specific exchanges (Bybit/OKX/Binance) and clarifying the 'any symbol or whole universe' default, but does not go beyond what the schema provides.

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 combination: per-exchange liquidation share for Bybit/OKX/Binance, with long/short split and biggest print. This distinguishes it from sibling tools like get_liquidation_stats or get_recent_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 phrase 'Which venue is flushing whom' implies a comparative use case, and 'any symbol or whole universe' suggests flexibility, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. Usage guidance is implied rather than 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a notable cost ($0.01 USDC per call) and the network (x402, Solana mainnet), which are important operational details. It also explains the calculation basis (daily closes), but does not detail response format or potential limitations for certain symbols.

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, front-loaded with the core purpose, then adds cost/network details. Every word earns its place; no fluff or repetition of schema 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?

For a simple one-parameter tool without an output schema, the description covers the key aspects: metrics computed, input scope, and cost. It implicitly describes return values by listing the volatility measures. A more explicit output format would be helpful, but the description is sufficiently complete for the tool's complexity.

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% coverage for the single `symbol` parameter, so the baseline is 3. The description adds minimal detail beyond the schema—it reiterates 'USDT perp' but does not clarify additional constraints or format beyond what the schema already provides.

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's function: computing realized volatility for any USDT perp with specific metrics (7d and 30d annualized from daily closes, plus today's range). This verb+resource+scope structure distinguishes it from siblings like get_sharp_move or get_squeeze_score, which focus on other volatility-related signals.

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 a clear use case ('Position-sizing input') but does not explicitly mention alternatives or when not to use it. The context is strong enough for an agent to select it for position sizing tasks, but it lacks explicit exclusions or comparative guidance against 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?

With no annotations, the description carries the burden. It discloses the per-call cost ($0.02 USDC), network (Solana mainnet), data source (Helius enhanced), and output includes failures. This is valuable behavioral context beyond the name/schema, though it omits error handling, rate limits, or authorization requirements.

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, front-loaded with purpose and output format, followed by cost/network metrics. Every sentence earns its place with zero 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?

For a simple two-parameter read tool, the description covers purpose, output structure, cost, and network. It lacks explicit references to error cases or pagination, but the output schema is absent and the description provides a reasonable summary of return fields, making it mostly 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% (both wallet and limit have descriptions). The description adds minimal semantic value beyond schema, only implying 'recent' via the tool overview. Since schema already documents parameter types and defaults, 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 fetches 'Recent transactions of any Solana wallet' and specifies the output format ('parsed human-readable: type, protocol, description, fee, failures'). This distinguishes it from sibling tools like get_wallet_holdings, which is about holdings, not activity.

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 retrieving recent Solana wallet transactions but does not explicitly compare with alternatives like get_wallet_holdings or mention when not to use this tool. The context is clear enough for basic selection, but no exclusions or alternative 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the cost per call ($0.008 USDC), the payment mechanism (x402), and the network (Solana mainnet). These are important operational behaviors beyond what the schema reveals. It does not explicitly state 'read-only', but the 'get' nature and content make that reasonably clear.

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, front-loaded with the core content (what the tool returns) followed by the cost detail. There is no redundant or filler text; every word contributes useful 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?

Despite having no output schema or annotations, the description covers the key aspects: the wallet address input (via schema), the contents of the response (SOL, SPL tokens with USD values, NFT count), the data source, cost, and network. It lacks details about the exact response structure or edge cases, but for a single-parameter read tool, this is reasonably 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 fully describes the only parameter ('wallet' as a base58 Solana address) with 100% coverage, so the baseline is 3. The description does not add additional parameter meaning, but the schema is sufficient, so no deduction is warranted.

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 returning Solana wallet holdings, listing specific contents (native SOL, SPL tokens with USD values, NFT count) and the data source (Helius DAS). This distinguishes it from siblings like get_wallet_activity (activity history) and get_token_holders (holders of a specific token).

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 about what the tool does (wallet holdings on Solana mainnet) and even notes the cost, which implies when one might use it (when needing a wallet portfolio snapshot). However, it does not explicitly state when to use it over alternatives or exclude other use cases, so usage guidance is implied rather than explicit.

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 the full burden. It discloses the cost ($0.02 USDC per call), the live tape source, and the aggregate outputs, which are useful behavioral details. However, it leaves gaps around return format, latency, pagination behavior, and handling of no-trade scenarios, so transparency is partial.

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 compact, with two sentences that effectively pack the core purpose, output summary, and cost. No filler words or redundant 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?

The tool has no output schema and no annotations, so the description must provide context about inputs and outputs. It covers the main purpose and cost, but does not fully clarify the return structure (e.g., whether it returns individual trade lists plus aggregates) or provide example usage, leaving some ambiguity for an agent to infer.

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. The description adds some context by mentioning 'trades over a USD threshold' and 'buy/sell totals', but it does not directly map these to specific parameters (min_usd, limit, symbol) beyond what the schema provides, so the added value is limited.

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 retrieving large whale trades from the live USDT perp tape, with a specific scope (any USDT perp) and output elements (threshold, buy/sell totals, net flow, dominant side). This distinguishes it from siblings like get_trade_context or get_orderbook_imbalance, which focus on different aspects.

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 the tool is for viewing large trades and flow data, but it does not explicitly state when to use it over alternatives or provide exclusions. No sibling comparison is offered, so usage guidance is only inferred from the described capabilities.

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 that the tool is free and returns a list, but it doesn't mention the response format, whether the list is exhaustive, or any potential caching or rate limits. For a simple read-only list, this is adequate but not rich.

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 that is both concise and front-loaded with 'Free:' to immediately convey cost. Every word adds value, and there is no fluff or 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 tool with no parameters and a simple output (a list), the description is sufficiently complete. It states the purpose and the key detail (USDC prices). Without an output schema, it doesn't detail the exact structure, but for a simple list this is a minor gap, so it earns a 4.

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 the baseline score is 4. The description doesn't need to explain any parameters since there are none. All schema coverage is effectively 100% as the schema is empty.

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 action: 'list all agentfeed tools with USDC prices.' It uses the specific verb 'list' and specifies the resource (all agentfeed tools). It distinguishes itself from sibling tools that fetch individual metrics, as this is a meta-listing tool.

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: you would call this tool to see an overview of all available tools and their USDC prices. However, it doesn't explicitly state when to use it or provide alternatives, and it doesn't mention exclusions. The 'Free:' prefix hints at a cost benefit but isn't a full usage guideline.

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