Bitget MCP — Crypto, DeFi & Macro Market Intelligence

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

The description discloses key behavioral traits: it uses VectorBT and ccxt, optionally generates charts (requires playwright), and supports pre-fetched OHLCV. It does not explicitly state if the backtest is read-only or if it modifies any state, but since no annotations are provided, the description adequately covers the main behavioral aspects.

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, approximately 80 words, with each sentence adding value. It is front-loaded with the main action and lists key features efficiently without redundancy.

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

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

Given the tool's complexity (8 parameters, no output schema), the description covers the overall purpose, input sources (exchange, pre-fetched data), and output metrics (return%, Sharpe, etc.). It mentions the optional chart generation but could elaborate on the strategy_config parameter. However, the schema descriptions fill some gaps, so completeness is high but not perfect.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context about the overall backtesting flow and mentions the ohlcv_json parameter for pre-fetched data, but it does not provide additional per-parameter details beyond what the schema already offers. Thus, it meets the baseline without exceeding.

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 defines the tool as running historical backtests on trading strategies using VectorBT, listing specific actions (fetching OHLCV, computing indicators, simulating portfolio) and output metrics. It distinctly separates itself from sibling tools which focus on market data and news rather than backtesting.

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 explains what the tool does but does not provide guidance on when to use it versus alternatives. No explicit when-not-to-use or alternative tools are mentioned. However, the context of sibling tools suggests this is the only backtesting tool, so the lack of explicit usage conditions is 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 full burden for behavioral disclosure. It mentions data sources and types but fails to disclose critical traits such as whether the tool is read-only, requires authentication, has rate limits, or any side effects. The action parameter implies different operations (e.g., 'price' for current price, 'search' for search), but no behavioral context is added beyond the enum names.

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 efficiently lists the tool's capabilities and data source. It is front-loaded with the key purpose. Slightly more structure (e.g., separate bullet points) could improve readability, but it is concise and clear.

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

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

Given no output schema and moderate complexity (6 parameters, 4 enums), the description covers the main actions and markets but lacks details on output format, error handling, symbol format variations (though hinted in schema), or prerequisites. It provides adequate but incomplete context for an agent to use the tool reliably.

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 83%, so the schema already documents most parameters. The description adds no additional meaning beyond what the schema provides for the parameters; it only repeats the data types. Baseline 3 is appropriate as the description does not compensate for the small uncovered portion.

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-share and HK stock data via AKShare, listing specific data types (OHLCV history, current price, symbol search, index daily data). However, it does not explicitly differentiate from sibling tools like cross_asset or global_assets, which may also cover Chinese markets, though the focus on AKShare and specific actions provides some distinction.

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 Chinese and Hong Kong stock data, but provides no explicit guidance on when to use this tool versus alternatives (e.g., crypto_market or global_assets). No when-not-to-use or context for choosing this tool over others 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?

Describes return values (Pearson correlation, rolling window, trend, interpretation) and notes no API key needed. Lacks details on data freshness, rate limits, or potential errors, but no annotations exist to contradict.

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 pack purpose, capabilities, and key advantage ('No API key required'). No wasted words; front-loaded with action verb.

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

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

Covers main functionality and outputs given no output schema. Mentions both full period and rolling correlation. Lacks specific output format (e.g., numeric values, text) but acceptable for a correlation 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 covers 100% of parameters, but description adds value by explaining default targets, base asset flexibility ('any other Yahoo Finance symbol'), and action types (correlation, assets_list, heatmap). Could link param details more explicitly.

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

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

Description clearly states it computes rolling cross-asset correlation, lists example assets (BTC, Gold, DXY, etc.), and specifies outputs (Pearson correlation, trend, interpretation). Distinguishes from sibling tools which focus on single asset prices or specific markets.

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?

States 'No API key required' and implies use for multi-asset correlation analysis. However, it doesn't explicitly exclude use cases like single asset data (which sibling tools handle). Could be more directive.

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 should disclose behavioral traits. It only lists data types and the use of ccxt, but omits side effects, rate limits, safety (read-only vs. mutation), or error behavior. This is a significant gap for a data retrieval tool.

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

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

The description is a single concise sentence with a clear list of capabilities. It is well-structured and avoids redundancy, though it could benefit from slightly more detail without losing brevity.

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

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

Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficient. It lacks explanation of output format, error handling, or parameter usage beyond the schema. More context is needed for an agent to use it reliably.

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

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

The input schema has 100% description coverage, so the schema already explains all parameters. The description's list of actions adds no extra meaning beyond the schema's action parameter description. Baseline is 3, and no additional value is provided.

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 crypto market data (price, klines, ticker, multi-symbol price) via ccxt exchange. It uses specific verbs and resources, making the purpose obvious. However, it does not explicitly differentiate from sibling tools like crypto_market or crypto_price, which may overlap.

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. The description does not mention context, prerequisites, or exclusions, leaving the agent without direction for tool selection among similar 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, the description carries full burden. It only lists data types but does not disclose behaviors like rate limits, read-only nature, error handling, or authentication needs. Highly opaque.

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 listing actions, but could be more front-loaded with purpose. No waste, but also no structure to aid quick scanning. Adequately concise.

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

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

No output schema. The tool has 8 parameters and a 6-value enum without explaining how actions map to required parameters or typical response format. Given complexity, the description is too high-level for reliable 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?

Schema coverage is 100% (all 8 parameters have descriptions), so baseline is 3. The description adds no extra parameter context beyond what's in the schema.

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

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

The description clearly states it provides CoinGecko crypto market data and lists the specific actions (search coins, price/OHLCV, market cap rankings, trending coins, global market stats). This differentiates it from sibling tools like crypto_price or defi_analytics, though not explicitly.

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

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

No guidance on when to use this tool vs alternatives like crypto_price or crypto_derivatives. The description does not mention prerequisites, exclusions, or context-specific recommendations.

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 a rate limit ('100K req/month free'), which is helpful. However, with no annotations provided, it fails to mention other behavioral aspects such as data freshness, error handling, or response format, limiting 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 a single concise sentence, which is efficient but lacks structure (e.g., bullet points or action-specific sections). It front-loads the core purpose but could be more organized for clarity.

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

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

Given the tool's moderate complexity and no output schema, the description provides the essential purpose and a rate limit. However, it omits context like whether prices are real-time, how to interpret the symbol list, or integration with sibling tools, making it somewhat incomplete.

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

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

Schema description coverage is 100%, so the parameters are well-documented in the schema itself. The description adds no additional semantic context beyond the schema, meeting the baseline expectation.

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 crypto price data and a symbol list, which aligns with the action parameter values 'price' and 'symbols'. However, it does not explicitly name these actions or differentiate from sibling tools like 'crypto_market' or 'crypto_derivatives', leaving room for confusion.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'backtest', 'crypto_market', and 'technical_analysis', the agent would benefit from explicit usage context, but none is given.

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

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

With no annotations, the description should disclose behavioral traits. It only lists data types and does not mention read-only nature, rate limits, data freshness, or any side effects. The agent cannot infer how the tool behaves beyond returning data.

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, making it concise. However, the run-on list of data types lacks structural clarity; it could enumerate actions distinctly.

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 5 parameters and no output schema or annotations, the description is incomplete. It fails to explain how the action parameter determines the data returned, how to use protocol slug, or what the output looks like. Significant gaps remain.

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 80%, so the schema provides decent parameter explanations. The description adds no additional parameter meaning; it just lists high-level data categories without linking them to the action enum or other 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 lists several DeFi data categories (TVL rankings, protocol details, etc.) but lacks a specific verb+resource statement. It vaguely describes what data can be retrieved but is a list rather than a clear action, making it ambiguous compared to sibling 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?

No guidance is provided on when to use this tool over alternatives like backtest, crypto_market, or global_data. There is no mention of context, prerequisites, or exclusions.

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

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

No annotations are provided, and the description does not disclose any behavioral traits such as rate limits, authentication, data freshness, or side effects. It fails to inform the AI agent about operational constraints beyond the parameter 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 a single, well-structured sentence that front-loads the core purpose and enumerates all data types. No unnecessary words or repetition. Efficient and clear.

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

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

The description covers the main data types but lacks details on output format, error handling, or how parameters interact. Given the tool's complexity (multiple sources, actions, parameters), more completeness would help the AI agent anticipate results and edge cases.

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?

Description adds domain-specific context to the action enum (e.g., 'reddit_trending' via ApeWisdom, 'long_short' from Binance), which enriches the schema descriptions. With 80% schema coverage, the description complements rather than repeats, providing meaningful semantic ties to real-world data sources.

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 social sentiment data with specific sources (ApeWisdom for Reddit, Binance for futures) and data types (long/short ratios, open interest, taker ratio). This distinguishes it from siblings like sentiment_index or crypto_derivatives.

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. No mention of prerequisites, exclusions, or preferred contexts. The description only lists data types without usage conditions.

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, and the description only states what the tool does without disclosing behavioral traits like read-only nature, rate limits, or side effects. While the tool appears to be a data retrieval tool, this is not explicitly confirmed.

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 listing all actions, which is concise and front-loaded with the data source. However, it mixes multiple capabilities without structuring them (e.g., using bullet points), which slightly reduces clarity.

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

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

Given the tool has 6 parameters, multiple actions, and no output schema or annotations, the description is insufficient. It does not explain how each action works, expected outputs, or any dependencies (e.g., chain required for search).

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 83%, meaning the schema already documents most parameters. The description adds no additional meaning beyond listing actions; it does not explain parameter relationships or constraints 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 that the tool accesses DexScreener DEX data for pairs, tokens, and trending boosts, which is specific. However, it does not differentiate from sibling tools like crypto_market that may also cover crypto data, relying entirely on the 'DexScreener' source for uniqueness.

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

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

The description provides no guidance on when to use this tool over alternatives such as crypto_market or cn_market. It lists actions but does not indicate prerequisites, context, 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 provided. Description mentions 'No API key', which is helpful, but lacks details on data freshness, rate limits, or other behavioral traits.

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

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

Single concise sentence front-loading 'Yahoo Finance data' with 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?

Adequately covers tool purpose and key parameters; missing details on return format (especially for 'ohlcv' vs 'price') but acceptable given 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 coverage is 75%; description adds value by providing symbol examples (e.g., BTC-USD, AAPL) but does not elaborate on action, period, or interval 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 it provides OHLCV history and current price for various asset types from Yahoo Finance, with specific symbol formats. It is distinct from siblings like 'cn_market' but does not explicitly differentiate 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?

Implies usage for Yahoo Finance data without API key, but no explicit when-not-to-use or alternatives among sibling tools are mentioned.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only lists data types without any information on rate limits, data freshness, caching, authentication, or error handling. For an external data fetching tool, this is insufficient.

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

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

The description is a single sentence that is concise and front-loaded with the key purpose ('World data:'). It wastes no words. However, it could benefit from more structure (e.g., bullet points) to improve scannability for an AI agent.

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

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

Given the tool's multiple actions and 8 parameters, the description is incomplete. It does not explain that parameters like latitude/longitude are specific to weather, or that query is for Wikipedia/arXiv. No output schema exists, but the description still should clarify action-specific usage, which it lacks.

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 high (88%), and most parameters have clear descriptions. The tool description adds some context (e.g., '150+ currencies' for forex) but does not significantly enhance understanding beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool provides multiple types of world data (forex, weather, Wikipedia, arXiv). It lists specific capabilities, distinguishing it from sibling tools that are more specialized (e.g., crypto_price, technical_analysis). However, it lacks a specific verb like 'get' or 'search', making the purpose slightly less direct.

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

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

The description provides no guidance on when to use this tool vs. alternatives. It does not mention when to prefer this aggregate tool over potentially more specific siblings (e.g., using this for forex vs. a dedicated forex tool). No context on prerequisites or exclusions 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 provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, rate limits, error behavior, or whether operations are destructive. The API key hint is 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?

Three concise sentences: first lists indicators, second states data source, third mentions API key requirement. No wasted words and front-loaded with purpose.

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

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

No output schema exists, but the description does not explain return format or structure. The actions (latest_release, history, fomc_news, etc.) are defined in the schema but not elaborated in the description, leaving the response type unclear.

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 lists some indicator names, but these are already covered in the schema's indicator parameter description. No additional parameter meaning is added.

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?

Describes tool as providing macro economic calendar and indicators, listing specific examples (CPI, NFP, etc.), and mentions data source (FRED). However, it is a noun phrase rather than a verb-led statement, slightly reducing clarity compared to the highest standard.

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?

Does not provide guidance on when to use this tool versus siblings like global_data or cross_asset. The only usage note is about setting FRED_API_KEY for higher rate limits, which is a prerequisite but not a usage guideline.

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 tool is for public data without API key requirements. However, it does not mention rate limits or data freshness, but for a simple data retrieval tool, 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?

A single, well-crafted sentence that conveys all essential information: public data, no API key, and specific data types. No wasted words.

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

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

Given the tool has one simple enum parameter and no output schema, the description covers most needed context. It lacks specific output format details but is sufficient 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 coverage is 100% and the action parameter's enum descriptions are fully detailed in the schema properties. The tool description adds overall context, making parameter semantics complete.

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 provides on-chain public data and lists specific items (ETH gas, BTC fees, mempool, blocks). It clearly differentiates from sibling tools (e.g., crypto_market, defi_analytics) which focus on different data types.

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 notes 'no API key', indicating no authentication is needed. It implies usage for public blockchain data. While it doesn't explicitly state when not to use or alternatives, the sibling list provides context and the use cases are clear.

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

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

No annotations are provided, so the description carries full burden. It states 'Aggregate news' (implying read-only) and 'No API key required,' but fails to disclose rate limits, update frequency, error handling, or any other behavioral traits beyond basic functionality.

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

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

Two concise sentences: the first covers the main purpose and categories, the second adds filtering and key requirement. No redundant information, front-loaded with key 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?

No output schema is provided, yet the description does not explain the structure of returned news articles (e.g., fields, pagination, ordering). The tool's behavior is only partially described, leaving an agent uncertain about the response format.

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

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

Schema description coverage is 100%, so the description adds limited value beyond what the schema already provides. It repeats that feeds are comma-separated and mentions categories, but does not add new semantic details about 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 clearly states it aggregates news from 44 RSS/Atom feeds across specified categories (crypto, macro, tech, etc.), with keyword filtering. It also distinguishes from siblings like tradfi_news by explicitly listing feed categories.

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 mentions 'No API key required' and suggests using action=sources to list feeds, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., tradfi_news) 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 present, so the description bears full responsibility. It discloses the data source (FRED) and the need for an API key for higher rate limits, but does not describe other behaviors (e.g., read-only nature, real-time vs. historical, error handling). This leaves significant gaps in understanding 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 two sentences, front-loaded with the main content (list of rates) and a second sentence on source/API key. It is concise, though the first sentence is a dense list. Every sentence adds value, but it could be split for readability.

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 (multiple actions, many rate keys, no output schema), the description is incomplete. It does not describe return formats, pagination, date ranges, or how each action works. With no output schema, the description should provide more detail on what the agent can 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%, so baseline is 3. The description lists example rate keys (t2y, t10y, etc.) mentioned in the schema, adding minimal value. It does not explain parameter usage beyond what the schema provides, so no improvement over 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 lists the specific US interest rates and bond yields provided (Treasury curve, Fed funds, etc.), making the resource clear. However, it lacks an explicit verb like 'get' or 'fetch', slightly reducing clarity. The sibling tools (e.g., global_assets, macro_indicators) are differentiated by the explicit focus on US rates.

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

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

No guidance is provided on when to use this tool versus siblings or alternatives. The description only mentions setting an API key for rate limits, not usage context. Without explicit when/when-not advice, an agent may not know to choose this over similar tools like macro_indicators.

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 disclose behavioral traits. It mentions data types (current, history, realtime) but lacks details on rate limits, data freshness, or whether it is read-only (presumed).

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 with no wasted words, efficiently conveying the tool's purpose.

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

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

The tool is simple and the description covers the three actions. However, lack of output schema means the agent does not know the return format, which could be improved with a brief note.

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%, baseline 3. The description adds value by associating 'realtime' with '5min intervals' and 'history' with 'past N days', which goes beyond the schema descriptions.

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

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

The description clearly states it is for the Crypto Fear & Greed Index and enumerates three modes (current, history, realtime), which distinguishes it from sibling tools like crypto_market or derivatives_sentiment.

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

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

The description implies usage for sentiment data but does not explicitly state when to use it versus alternatives or provide conditions for when not to use it, which would be helpful given the many 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 provided; description only mentions 'Three-provider failover' without explaining fallback behavior, rate limits, or authentication needs. Behavioral details are insufficient.

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

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

Short and to the point, with no redundant sentences. However, the structure could be improved by separating platform list from the purpose.

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

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

Given the complexity (multiple actions, platforms, failover), the description lacks details on output format, failover behavior, and error handling. Without an output schema, more context is needed.

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 adequate descriptions for all parameters. The description adds marginal value by listing platforms in prose, but does not clarify action semantics 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 providing social media trending lists from multiple platforms (Douyin, Weibo, etc.), distinguishing it from sibling tools focused on markets, crypto, and news.

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

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

No explicit guidance on when to use this tool versus alternatives like news_feed or sentiment_index. The description does not mention prerequisites 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 bears full responsibility for behavioral disclosure. It only lists indicator names without any details on data sources, accuracy, latency, or whether modifications are involved. The description does not disclose traits beyond the listed features.

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 with no unnecessary words. It is concise and front-loaded with the core purpose, though it could benefit from slight restructuring to improve readability.

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 omits any return value information, which is critical since there is no output schema. It also lacks guidelines on parameter combinations or usage scenarios. Given the tool's complexity (multiple actions), more detail is needed.

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 80% coverage, so the baseline is 3. The description enumerates actions (rsi, macd, etc.) which adds context to the 'action' parameter, but does not elaborate on other parameters beyond the schema. It provides marginal 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 lists the types of technical analysis (RSI, MACD, etc.) but lacks a strong action verb like 'calculates' or 'retrieves'. It conveys the general purpose but is not as clear as it could be, especially considering sibling 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?

No guidance on when to use this tool versus alternatives such as backtest or crypto_market. The description does not mention context, prerequisites, or exclusions.

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

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

With no annotations, the description carries full burden but only discloses the API key requirement. It fails to mention that the tool is read-only, any rate limits, error handling, or behavior beyond data retrieval.

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 with no wasted words, front-loading the key purpose ('Finnhub financial data'). It could be slightly improved by structuring the actions as a list, but it remains 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?

With 5 parameters (1 required), no output schema, and no annotations, the description lacks sufficient context about how parameters interact, what the return format is, and the overall workflow.

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 have descriptions), so baseline is 3. The description adds no additional meaning to parameters beyond what the schema provides, such as explaining how action values map to data sources.

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 Finnhub financial data including earnings, news, crypto news, and company profiles, which differentiates it from sibling tools like news_feed. However, it could be more specific about how the action parameter selects the data type.

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

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

The description mentions the requirement for FINNHUB_API_KEY but provides no guidance on when to use this tool versus alternatives, no context on when to avoid it, and no explicit usage scenarios.

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