AlgoVault — Crypto Quant Trade Calls

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

The description discloses that the tool returns synthesized answers with citations, is read-only (consistent with readOnlyHint annotation), and has quota limits. No contradictions with annotations.

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

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

Four sentences with no wasted words. Core purpose is front-loaded, followed by usage guidance and quota. 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?

Given no output schema, the description adequately describes the output (synthesized answer with citations) and includes quota limits. It lacks error handling details but is sufficient for the tool's simplicity.

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

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

Schema covers both parameters with descriptions (100% coverage). The description adds value by explaining the default model and that the question is natural-language (5-500 chars), reinforcing the schema but not contradicting it.

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

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

The description clearly states the tool's purpose: asking a natural-language question to get a synthesized answer with citations grounded in the knowledge bundle. It uses specific verbs ('ask', 'get') and distinguishes from the sibling 'search_knowledge' 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?

Explicitly tells when to use this tool (for explanations, code patterns, how-to answers) and when to use 'search_knowledge' (for raw snippets, faster, no quota cost). Also provides quota information, helping the agent decide based on constraints.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with open-world data. The description adds valuable context about the classification methodology (ADX(14), volatility ratio, price structure, cross-venue funding sentiment) that goes beyond what annotations provide, though it doesn't mention rate limits or authentication 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?

Single sentence efficiently conveys the tool's purpose, output categories, and methodology without unnecessary words. Every element serves a clear purpose in helping the agent understand what the tool does.

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

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

For a read-only classification tool with good annotations and comprehensive parameter documentation, the description provides adequate context about what the tool does and how it works. The main gap is lack of output format details (since no output schema exists), but the description does specify the four possible classification categories.

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?

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional semantic value.

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

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

The description clearly states the specific action ('Classifies'), the resource ('current market regime'), and the output categories (TRENDING_UP, TRENDING_DOWN, RANGING, VOLATILE). It distinguishes from siblings by focusing on regime classification rather than trade signals or funding arbitrage scanning.

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 market regime analysis on Hyperliquid perps using specific technical indicators, but doesn't explicitly state when to use this tool versus the sibling tools (get_trade_signal, scan_funding_arb). No explicit exclusions or alternative scenarios 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds minimal behavioral info beyond listing the indicators used. It does not disclose potential rate limits, data freshness, or result stability.

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

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

Single, front-loaded sentence that directly describes the tool's function without extraneous text. Every word 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?

Given no output schema and 4 parameters, the description adequately explains the composite nature and output type (weighted score with confidence). However, it lacks details on return format or example values, which would enhance completeness.

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

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

Input schema has 100% coverage with detailed descriptions for all 4 parameters. The description does not add extra meaning beyond the schema; it only mentions the indicators combined but not parameter specifics.

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 returns a composite BUY/SELL/HOLD trade call for perpetuals on specified exchanges, combining multiple indicators. This specific verb and resource clearly distinguishes it from siblings like get_trade_signal or scan_funding_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 implies use for trading decisions but does not explicitly state when to use this tool versus alternatives like get_trade_signal or get_market_regime. No exclusion criteria or context for choosing 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with open-ended data. The description adds valuable behavioral context beyond annotations: it explains the composite nature of the signal, the specific indicators used (RSI, EMA, funding rate, OI momentum, volume), and that it produces a weighted score with confidence percentage. This provides important implementation details not captured in annotations.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose, methodology, and output format. Every element serves a purpose: the action ('Returns'), target ('Hyperliquid perp'), output type ('composite BUY/SELL/HOLD signal'), methodology ('Combines...into a weighted score'), and confidence metric. Zero wasted words.

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

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

For a read-only tool with comprehensive schema coverage and no output schema, the description provides good context about what the tool does and how it works. It explains the composite nature of the signal and the specific indicators used, which helps the agent understand the tool's behavior. The main gap is lack of explicit output format details, but given the annotations and schema completeness, 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?

With 100% schema description coverage, the schema already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

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

The description clearly states the tool's purpose: 'Returns a composite BUY/SELL/HOLD signal for a Hyperliquid perp' with specific technical indicators listed (RSI, EMA crossover, funding rate, OI momentum, volume). It distinguishes from siblings like 'get_market_regime' and 'scan_funding_arb' by focusing on trade signals rather than market regimes or arbitrage opportunities.

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

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

The description implies usage context through the mention of 'Hyperliquid perp' and technical indicators, but doesn't explicitly state when to use this tool versus alternatives. It doesn't provide explicit 'when-not' guidance or named alternatives beyond what's implied by sibling tool names.

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

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

Annotations indicate read-only and open-world hints, which the description aligns with by describing a scanning/returning operation without implying mutation. The description adds valuable behavioral context beyond annotations: it specifies the exact exchanges scanned (Hyperliquid, Binance, Bybit), the ranking criterion (annualized spread), and the output format (top opportunities), enhancing the agent's understanding of the tool's behavior.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and output without any redundant or unnecessary information. It is front-loaded with the core action and immediately follows with key details, making it highly concise and effective.

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

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

Given the tool's moderate complexity (scanning multiple exchanges for arbitrage), rich annotations (readOnlyHint, openWorldHint), and 100% schema coverage, the description is largely complete. It covers the what, where, and output ranking, though it lacks details on response format (e.g., structure of returned opportunities) and any rate limits or authentication needs, which are not provided elsewhere.

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

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

The input schema has 100% description coverage, fully documenting both parameters (limit and minSpreadBps) with defaults and constraints. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining basis points or free tier limits, so it meets the baseline score of 3 for high schema coverage.

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

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

The description clearly states the specific action ('Scans'), resources ('cross-venue funding rate differences between Hyperliquid, Binance, and Bybit'), and outcome ('Returns top arbitrage opportunities ranked by annualized spread'). It precisely distinguishes this tool from its siblings (get_market_regime, get_trade_signal) by focusing on funding rate arbitrage scanning rather than market regime analysis or trade signal generation.

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 seeking arbitrage opportunities based on funding rate differences across specific exchanges, but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The context is clear but lacks comparative or conditional direction.

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

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

Discloses it uses BM25 lexical search, no LLM call, no quota cost. Annotations already indicate readOnly and openWorld; the description adds valuable performance and cost context beyond annotations.

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

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

Description is concise and well-structured, starting with purpose, then usage guidance, then behavioral details. Every sentence adds value; 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?

Fully covers what the tool does, when to use it, behavioral traits, and parameter constraints. No gaps for the given task, even without an output schema.

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

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

Input schema has 100% coverage with clear descriptions for query and limit. Description adds no extra parameter meaning beyond restating functionality. Baseline score 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?

Clearly states the tool searches the knowledge bundle for MCP tool info, integration patterns, etc., and distinguishes from chat_knowledge by noting it's a fast lexical search returning ranked snippets.

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 advises using this BEFORE any tool call to confirm parameters, and contrasts with chat_knowledge for synthesized answers. No ambiguity about when to use alternatives.

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