A comprehensive market data MCP server maintained by Bitget, aggregating 20 tools across crypto, DeFi, derivatives, TradFi, macro, and on-chain data
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.3/5 across 19 of 19 tools scored. Lowest: 2.6/5.
Multiple tools overlap in providing crypto price data (crypto_price, crypto_market, crypto_derivatives, global_assets) and news (news_feed, tradfi_news). While descriptions clarify some differences, agents may struggle to choose between similar tools.
Tool names mix styles: some are simple nouns (backtest, cn_market), others compound nouns with underscores (crypto_derivatives, derivatives_sentiment). No consistent verb_noun pattern, making it harder to infer purpose from name alone.
With 19 tools covering a broad domain (crypto, DeFi, macro), the count feels slightly high but justifiable. However, several tools could be merged to reduce overlap and improve navigability.
The tool set covers a wide range of market intelligence needs: price data, technical analysis, sentiment, macro indicators, news, and DeFi. Minor gaps like on-chain analytics or direct trading are acceptable given the intelligence focus.
backtestAInspectRun historical backtests on trading strategies using VectorBT. Fetches OHLCV from exchange (ccxt), computes indicators (RSI/MACD/BB/EMA/ATR), evaluates entry/exit signals, simulates portfolio, returns structured metrics (return%, Sharpe, max drawdown, win rate, profit factor). Optionally generates equity curve chart. Supports pre-fetched OHLCV via ohlcv_json for coingecko/yfinance data.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | run=execute backtest, chart=regenerate chart from previous metrics | |
| period | No | Lookback period, e.g. '6m', '1y', '30d'. Default: 6m | |
| exchange | No | Exchange for OHLCV data. Default: binance | |
| ohlcv_json | No | Pre-fetched OHLCV as JSON string (from coingecko/yfinance tools). Format: {"SYMBOL": [{"timestamp":ms,"open":...,"close":...}, ...]} | |
| metrics_json | No | For action=chart: JSON metrics from a previous run. | |
| generate_chart | No | Generate equity curve chart (requires playwright). Default: false | |
| strategy_config | No | JSON string with strategy config. Keys: name, symbols (list), timeframe, indicators (list of {name, params, key}), entry_conditions (list of {indicator, field, operator, value}), exit_conditions, direction (long/short/both), stop_loss_pct, take_profit_pct, trade_size_pct, fees. | |
| starting_balance | No | Initial cash. Default: 100000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavior: fetching OHLCV, computing indicators, evaluating signals, simulating portfolio, returning metrics, and optional chart generation requiring playwright. It omits potential errors or performance details but is generally 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 a concise 3-sentence paragraph that front-loads the main purpose, then details the process, and ends with a special feature. 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?
Given the tool's complexity and lack of output schema, the description provides a solid overview of inputs, process, and outputs. It mentions metric names and the chart requirement. Minor omissions include error handling and system dependencies (except playwright).
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 description adds context by naming specific indicators, metrics, and the ability to use pre-fetched data. It complements the schema descriptions effectively.
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 runs historical backtests using VectorBT, listing specific steps and outputs. It distinguishes itself from sibling data/analysis tools by focusing on backtesting and portfolio simulation.
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 backtesting trading strategies but does not explicitly mention when to avoid or provide alternatives among siblings. However, the context makes it clear this is the backtesting tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cn_marketBInspectA-share and HK stock data via AKShare: OHLCV history, current price, symbol search, index daily data.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Calendar days of history (default 365) | |
| action | Yes | ||
| adjust | No | Price adjustment: empty=none, qfq=forward, hfq=backward | |
| market | No | Market: a=A-share (default), hk=Hong Kong | |
| period | No | Period (default: daily) | |
| symbol | No | A-share code (000001), HK code (00700), index (sh000001) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions data source (AKShare) but does not disclose behavioral traits like rate limits, data freshness, whether it is read-only, or if authentication is needed. For a data retrieval tool, stating read-only nature would be 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 a single sentence of 16 words, listing the core functionalities without any fluff. It is front-loaded and 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?
Despite having 6 parameters and no output schema, the description is very brief. It does not explain how parameters relate to actions (e.g., symbol required for ohlcv) or how to format symbol codes. The description is incomplete for making effective use of all tool capabilities.
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 most parameters are already described in the schema. The description adds high-level context but does not provide additional meaning beyond what the schema offers. 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?
Description clearly states it provides A-share and HK stock data, listing specific data types (OHLCV history, current price, symbol search, index daily data). The name and description distinguish it from sibling tools focused on other asset classes like crypto or global assets.
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?
Description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context about when this tool is appropriate, prerequisites, or exclusions. The many sibling tools make such guidance valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cross_assetAInspectRolling cross-asset correlation: BTC vs Gold, DXY, Nasdaq, S&P500, 10Y Treasury yield, EUR/USD, oil, VIX, and any other Yahoo Finance symbol. Returns Pearson correlation (full period + rolling window) with trend and interpretation. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base asset key or Yahoo Finance symbol (default: btc → BTC-USD) | |
| action | Yes | correlation=compute correlation between base and targets, assets_list=list available asset keys and Yahoo symbols, heatmap=full correlation matrix for a set of assets | |
| assets | No | Comma-separated assets for heatmap (default: btc,gold,dxy,ndx,spx,t10y,oil) | |
| period | No | Lookback period (default: 1y) | |
| window | No | Rolling window in trading days (default: 30, range: 5-252) | |
| targets | No | Comma-separated target asset keys or Yahoo symbols. Default: gold,dxy,ndx,spx,t10y,vix. Use assets_list action to see available keys. |
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 return values (Pearson correlation with trend and interpretation) and states 'No API key required.' No destructive behavior is expected, and no contradictions 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 a single sentence that packs all essential information without redundancy. It could be slightly more structured, but it efficiently front-loads 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?
Despite having no output schema, the description explains what is returned (Pearson correlation with trend and interpretation) and covers all actions and parameters. The tool has 6 parameters with 1 required, and the description is comprehensive enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by explaining default values (e.g., 'base asset key or Yahoo Finance symbol (default: btc → BTC-USD)') and usage notes for actions like 'assets_list'.
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 computes 'Rolling cross-asset correlation' between BTC and multiple specified assets, with the ability to use any Yahoo Finance symbol. This specific verb+resource combination distinguishes it from sibling tools like 'crypto_market' or 'global_assets'.
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 correlation analysis across assets and mentions no API key is required, but lacks explicit guidance on when not to use it or alternatives. Given the distinct siblings, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crypto_derivativesCInspectCrypto market data via ccxt exchange. Covers: price, klines (OHLCV), 24h ticker, multi-symbol price.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (1-500, default 50) | |
| action | Yes | Action to perform: price, klines, ticker_24h, multi_price. | |
| symbol | No | Trading pair, e.g. BTC/USDT | |
| symbols | No | Comma-separated symbols for multi_price | |
| exchange | No | Exchange name (default: Binance) | |
| timeframe | No | Kline timeframe, e.g. 1h, 4h, 1d (default: 4h) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions data source (ccxt exchange) but does not reveal important traits like rate limits, data freshness, idempotency, or safety (read-only assumption not stated). This is insufficient for a data-fetching 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 concise sentences that are front-loaded and without wasted words. Every sentence adds value: first states purpose and data source, second enumerates covered data types.
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 6 parameters, no output schema, and no annotations, the description is too brief. It does not explain return values, pagination (limit parameter), or how to construct multi-symbol requests. The tool's complexity demands more detail for an agent to use 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?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds marginal value by listing action options in prose, but does not provide additional semantics beyond what the schema already conveys. 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 crypto market data via ccxt exchange and lists specific data types (price, klines, ticker, multi-symbol price). However, it does not differentiate from sibling tools like crypto_market or crypto_price, which likely have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like crypto_market or crypto_price. The description lacks any context about prerequisites, best practices, or when not to use it, which is critical 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.
crypto_marketCInspectCoinGecko crypto market data: search coins, get price/OHLCV, market cap rankings, trending coins, global market stats.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of OHLCV history (1/7/30/90/180/365, default 180) | |
| page | No | Page number (default 1) | |
| query | No | Search query (action=search) | |
| action | Yes | Action to perform | |
| coin_id | No | Single CoinGecko ID for ohlcv, e.g. 'bitcoin' | |
| coin_ids | No | Comma-separated CoinGecko IDs for price, e.g. 'bitcoin,ethereum' | |
| per_page | No | Results per page for markets (default 20, max 250) | |
| vs_currency | No | Quote currency (default: usd) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions the data source (CoinGecko) but does not disclose behavioral traits such as rate limits, authentication requirements, data freshness, or whether the tool is read-only. This is a significant gap.
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 all available data types. It is concise, but for a multi-action tool, a structured format (e.g., bullet points) could improve readability and action mapping.
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 8 parameters and multiple distinct actions, the description lacks detail on what each action returns (no output schema). Key information like default vs_currency and pagination defaults are in the schema but not elaborated. The description is too high-level for an agent to use confidently without further investigation.
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 parameters are already documented. The description does not add extra meaning or context beyond listing the actions; 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 provides CoinGecko crypto market data and enumerates specific actions (search, price, OHLCV, markets, trending, global). However, it does not differentiate from sibling tools like crypto_price, which may partially 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?
The description provides no guidance on when to use this tool over its siblings (e.g., crypto_price, crypto_derivatives). An agent must infer usage solely from the listed actions, which is insufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crypto_priceBInspectFreeCrypto: crypto price data and symbol list (100K req/month free).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max symbols returned for action=symbols (1-200, default 50) | |
| action | Yes | price=get price for symbols, symbols=list all available | |
| symbol | No | Comma-separated base symbols, e.g. 'BTC,ETH,SOL' (max 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the rate limit, which is a behavioral constraint. However, with no annotations, it lacks detail on side effects, idempotency, or whether it requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence covering functionality and a key limitation. 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?
For a simple tool with 3 parameters and no output schema, the description covers the basics. However, it lacks differentiation from siblings and does not explain 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 coverage is 100%, so the description does not need to add parameter details. It does not provide extra context beyond what the schema already describes.
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 crypto price data and a symbol list, which aligns with the tool name and distinguishes it from siblings like 'crypto_derivatives' and 'defi_analytics'. It could be more specific about whether prices are current or historical.
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. It mentions a rate limit ('100K req/month free') but does not indicate when to choose this over other crypto tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
defi_analyticsCInspectDeFiLlama DeFi data: TVL rankings, protocol details, chain stats, protocol fees/revenue, yield pools, stablecoin market caps.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Filter by chain name | |
| limit | No | Max results (1-100) | |
| action | Yes | ||
| min_tvl | No | Min TVL filter for yields (default 1000000) | |
| protocol | No | Protocol slug (action=protocol) |
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 does not disclose any behavioral traits such as authentication requirements, rate limits, or side effects. The tool is read-only by nature, but that is not explicitly stated. The description only lists data types, leaving the agent unaware of operational constraints.
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, direct sentence that front-loads the key information (source and data types). It is not verbose and avoids fluff. However, it is somewhat list-like and could be structured to better separate actions, but overall it is appropriately 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?
The tool has 6 distinct actions and 5 parameters, yet no output schema exists. The description does not hint at what each action returns (e.g., arrays of objects, numerical values). Without output schema, the agent needs more context about return formats. The brief list of data categories is insufficient for a multifunction DeFi data 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 80%, meaning most parameters have descriptions in the schema. The tool description adds little beyond listing the broad categories; it does not explain how each action parameter affects the output or what the 'min_tvl' filter does in proportion to 'yields.' The schema already covers parameter basics, so the description provides marginal semantic enrichment.
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 lists the data categories (TVL rankings, protocol details, chain stats, fees/revenue, yield pools, stablecoins) and names the source (DeFiLlama). It distinguishes this tool from sibling tools like crypto_market by focusing on DeFi analytics. However, it lacks a strong action verb like 'retrieve' or 'query,' so it's slightly less explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for DeFi data from DeFiLlama, but does not mention when not to use it or point to other sibling tools for related but different data. This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
derivatives_sentimentCInspectSocial sentiment data: Reddit crypto trending (ApeWisdom), Binance futures long/short ratios, open interest history, taker buy/sell ratio.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50, default 20) | |
| action | Yes | ||
| filter | No | Subreddit filter for reddit_trending (default: all-crypto) | |
| period | No | Period for Binance endpoints (default: 4h) | |
| symbol | No | Futures symbol for Binance endpoints (default: BTCUSDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It lists data types but does not disclose behavioral traits like data freshness, rate limits, or whether it requires authentication. The tool is clearly read-only, but that is not explicitly 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 a single concise sentence that efficiently lists key data sources. It is front-loaded with 'Social sentiment data', which is the core purpose. However, it could be structured to separate the data categories more clearly.
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 5 parameters, multiple action enums, and no output schema. The description is minimal and does not explain how each action works, what data is returned, or how parameters like 'filter' and 'period' affect results. More detail is needed for an agent to use this tool 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?
Input schema covers 80% of parameters with descriptions (e.g., limit, action, filter, period, symbol). The description adds context about the data sources but does not elaborate on parameter behavior beyond the schema. Baseline score of 3 is appropriate given the 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 that the tool provides 'Social sentiment data' and lists specific data sources (Reddit trending from ApeWisdom, Binance futures metrics). This distinguishes it from siblings like 'social_trending' or 'crypto_derivatives' by specifying exact sources, but it could be more explicit about the aggregation of social and derivatives 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 on when to use this tool versus alternatives such as 'crypto_derivatives' or 'social_trending'. The description simply lists available data without context on use cases, prerequisites, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dex_marketBInspectDexScreener DEX data: search pairs/tokens, get specific pair info, token details by address, trending token boosts.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Blockchain ID, e.g. ethereum, solana, bsc | |
| limit | No | Max results (1-30, default 10) | |
| query | No | Search query (action=search) | |
| action | Yes | ||
| pair_address | No | Pair contract address (action=pair) | |
| token_address | No | Token address, optionally prefixed with 'chain/' (action=token) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does mention the tool returns 'data' but fails to disclose behavioral traits like read-only nature, rate limits, pagination, or error handling. For a data retrieval tool, this is minimally adequate but lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence covers the core functionality and lists actions without unnecessary words. It is front-loaded but could be better structured (e.g., bullet list) for clarity. No fluff, but brevity sacrifices granularity.
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 moderate complexity (6 params, enum action), no output schema, and no annotations, the description does not explain return values or behavior beyond action types. It is adequate for a straightforward data retrieval tool but leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 83% coverage (likely all but one param have descriptions). The description groups actions but adds little beyond the schema—it does not explain parameter relationships or constraints. With high schema coverage, 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 DexScreener DEX data and lists the four actions (search, pair, token, trending). However, it does not differentiate from sibling tools like crypto_market or defi_analytics, which may also provide market data. The purpose is specific but lacks explicit 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?
No guidance on when to use this tool versus alternatives. The description implies usage for DEX queries but does not mention prerequisites, context, or when not to use it. Sibling tools cover similar domains, making guidance essential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
global_assetsCInspectYahoo Finance data: OHLCV history and current price for stocks, ETFs, crypto (BTC-USD), forex (EURUSD=X), futures (GC=F). No API key.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| period | No | History period (default: 1y) | |
| symbol | Yes | Yahoo Finance symbol: BTC-USD, AAPL, EURUSD=X, GC=F, SPY | |
| interval | No | Bar interval (default: 1d) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. Only mentions 'No API key' but omits rate limits, real-time vs delayed data, or any usage constraints.
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 is highly concise and front-loaded with core purpose. No unnecessary 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?
No output schema, but description does not explain return format, pagination, or whether multiple symbols can be queried. Missing critical context for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 75% of parameters with descriptions, and the description adds asset-type examples for symbol. However, no extra meaning for action or how period/interval interact.
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 provides OHLCV history and current price from Yahoo Finance for multiple asset types. However, it does not explicitly differentiate from sibling tools like crypto_market or cn_market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lists capabilities but does not specify preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
global_dataCInspectWorld data: forex exchange rates (150+ currencies), weather forecast, Wikipedia article summaries, arXiv paper search.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency for forex (default: USD) | |
| lang | No | Wikipedia language (default: en) | |
| limit | No | Max results (1-20, default 5) | |
| query | No | Search query for wikipedia/arxiv | |
| action | Yes | ||
| symbols | No | Comma-separated target currencies | |
| latitude | No | Latitude for weather | |
| longitude | No | Longitude for weather |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only lists capabilities without disclosing behavioral traits like rate limits, data freshness, permissions, or side effects (though likely read-only). Lacks important context for agent decision-making.
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 that effectively front-loads the purpose and lists specific data categories. No wasted words; 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 multi-action tool with 8 parameters and no output schema, the description is too brief. It does not explain parameter dependencies per action (e.g., weather requires lat/lon) or return format, leaving agents underinformed.
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 88%, so the input schema documents most parameters. The description adds no extra meaning beyond listing the four actions, which is already captured in the 'action' enum.
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 lists four distinct data domains (forex, weather, Wikipedia, arXiv) with specific details like number of currencies. It clearly states what the tool provides, distinguishing it from siblings that focus on single domains.
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 siblings like 'forex' or 'weather' tools. The description does not mention prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
macro_indicatorsAInspectMacro economic calendar and indicators: CPI, Non-Farm Payrolls, FOMC decisions, GDP growth, unemployment, retail sales, PPI, ISM PMI, and more. Data from FRED (Federal Reserve). Set FRED_API_KEY for higher rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of historical observations (default 12, max 120) | |
| action | Yes | latest_release=most recent value for an indicator, history=historical series data, fomc_news=recent Fed monetary policy news from RSS, multi_indicator=key macro snapshot (CPI+NFP+GDP+unemployment), series_list=list available indicator keys | |
| indicator | No | Indicator key, e.g. 'cpi', 'nonfarm_payrolls', 'gdp_growth', 'unemployment', 'core_pce', 'ppi', 'consumer_sentiment', 'retail_sales', 'industrial_production'. See action=series_list for full list. | |
| indicators | No | Comma-separated indicator keys for multi_indicator action |
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 data source (FRED) and mentions that setting an API key increases rate limits. However, it does not mention whether the tool is read-only, any potential side effects, or rate limits without the key. This is adequate but not comprehensive.
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, consisting of two sentences that immediately convey the tool's purpose, coverage, and a practical note about rate limits. Every word adds value, and the structure is front-loaded with 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?
The tool has no output schema, so the description should explain what the return values look like. It does not describe the output format, pagination, or error handling. For a data-fetching tool with multiple actions, this is a significant gap.
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 adds minimal extra meaning beyond the schema; it lists example indicators and mentions the API key, but these are already implied by the schema's description fields. No additional semantic depth is provided for 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 macro economic calendar and indicators, listing specific examples (CPI, Non-Farm Payrolls, FOMC decisions, etc.) and the data source (FRED). This distinguishes it from sibling tools like news_feed or tradfi_news, which focus on news rather than structured economic data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use (to fetch macro economic data) and mentions setting FRED_API_KEY for higher rate limits. However, it does not explicitly state when not to use this tool or suggest alternatives for related tasks like news or technical analysis, which is acceptable given the sibling list implies those uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
network_statusAInspectOn-chain public data (no API key): ETH gas prices, BTC recommended fees, mempool stats, and recent blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | eth_gas=Ethereum gas prices, btc_fees=recommended BTC fees, btc_mempool=mempool stats, btc_blocks=recent blocks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool is read-only and public, listing specific data types. It does not mention rate limits, data freshness, or response structure, but given the tool's simplicity, 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?
The description is one concise sentence with no wasted words. It efficiently conveys the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and no output schema, the description is fairly complete in telling what data is returned. However, it could specify the output format or structure to reduce uncertainty for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the enum values in detail. The description adds no extra parameter meaning. 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 specifies the tool provides on-chain public data including ETH gas prices, BTC recommended fees, mempool stats, and recent blocks. It distinguishes itself from sibling tools which focus on market, sentiment, and other financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'On-chain public data (no API key)' indicating free access, which provides some usage context. However, it does not explicitly mention when to use this tool versus alternatives like crypto_market or crypto_price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_feedAInspectAggregate news from 44 RSS/Atom feeds: crypto, macro, tech, geopolitics, science. Filter by keyword. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| feeds | No | Comma-separated feed keys, or 'all' (default). See action=sources. | |
| limit | No | Max articles per feed (1-10, default 5) | |
| action | Yes | latest=fetch articles, sources=list available feed keys | |
| keyword | No | Case-insensitive keyword filter on title+summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses 'No API key required' but lacks information on rate limits, error handling, or the exact format of returned data. Behavioral traits beyond fetching are not addressed.
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 purpose and includes key details (feeds, categories, filter, no API key). 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 4 parameters and no output schema, the description covers core functionality and filtering. Missing details about return format (e.g., article fields) and pagination behavior, but 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 description adds value by elaborating on filtering ('Filter by keyword') and source listing ('See action=sources'), which are not fully captured in schema descriptions 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 clearly states the tool aggregates news from 44 RSS/Atom feeds across specified categories and supports keyword filtering. It distinguishes from siblings like 'tradfi_news' by mentioning broad categories (crypto, macro, tech, etc.).
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 news aggregation but does not explicitly guide when to use it vs. alternatives like 'tradfi_news' or 'social_trending'. No exclusions or when-not-to-use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rates_yieldsBInspectUS interest rates and bond yields: Treasury yield curve (3M/1Y/2Y/5Y/10Y/30Y), Federal funds rate and target bands, SOFR, mortgage rates, credit spreads, 10Y-2Y spread (recession indicator), breakeven inflation. Data from FRED (Federal Reserve). Set FRED_API_KEY for higher rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of observations for history (default 30, max 252) | |
| action | Yes | yield_curve=full Treasury yield curve snapshot, fed_funds=current Fed funds rate + target bands, rate=specific rate by key, history=historical series, rates_snapshot=key rates dashboard (yield curve + Fed + spreads), series_list=list available rate keys | |
| rate_key | No | Rate key for rate/history actions: t2y, t10y, t30y, t3m, fed_funds, fed_funds_target_upper, spread_10y2y, breakeven_10y, sofr, prime_rate, mortgage_30y, hy_spread, ig_spread, tips_10y. See action=series_list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses data source (FRED) and mentions rate limits via API key, but does not detail request behavior, error handling, or output format. Some behavioral context is provided, but gaps remain.
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 paragraph that efficiently conveys the tool's scope and a practical note about API keys. It is front-loaded and each sentence adds value, though it could be slightly more 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 omits return format and error handling. It provides sufficient detail for a data retrieval tool but lacks completeness on what the agent can expect from the response.
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 adds some context (e.g., '10Y-2Y spread (recession indicator)') but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides US interest rates and bond yields, listing specific data types (Treasury curve, Fed funds, SOFR, etc.). It differentiates from sibling tools by focusing solely on rates/yields, making its purpose unmistakable.
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 explain when to use this tool over alternatives like macro_indicators or cross_asset. It only mentions setting an API key for rate limits, lacking explicit context on usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sentiment_indexBInspectCrypto Fear & Greed Index: current value, historical data, and real-time granular readings.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history (1-365, default 30) | |
| hours | No | Hours of realtime data (1-192, default 24) | |
| action | Yes | current=latest index, history=past N days, realtime=5min intervals |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the three output modes (current, history, realtime) which partially covers behavior, but it omits details like rate limits, data source, or what happens on errors. The description is minimally 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?
The description is a single concise sentence with good front-loading of the key concept. It could be slightly more structured (e.g., listing the three capabilities explicitly), but it is efficient 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?
Given the lack of an output schema, the description should provide more detail about what the tool returns (e.g., numerical index, classification labels). It only hints at the output format. For a tool with many siblings, this incompleteness may hinder correct selection.
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 all three parameters, so the baseline is 3. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the Crypto Fear & Greed Index and specifies three distinct capabilities: current value, historical data, and real-time granular readings. This is specific and distinguishes it from sibling tools like derivatives_sentiment or crypto_market.
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 versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technical_analysisBInspectTechnical analysis on crypto pairs: RSI, MACD, Bollinger Bands, MA/EMA, ATR, support/resistance levels, full composite analysis, and batch analysis for multiple symbols.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| period | No | Indicator lookback period (2-500, default: 14) | |
| symbol | No | Trading pair, e.g. BTC/USDT (required for single-coin actions) | |
| symbols | No | Comma-separated pairs for batch_analysis | |
| timeframe | No | Candle timeframe: 1h, 4h, 1d, etc. (default: 4h) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention that the tool is read-only, whether it requires authentication, rate limits, or data freshness. The description only lists capabilities without any 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 a single, run-on sentence listing many items. While it is reasonably concise, it lacks structure (e.g., bullet points) that would improve readability. It earns its place but could be more 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?
With no output schema and complex multi-action functionality, the description should explain what each analysis returns. It only lists analysis names without details. For a tool with 5 parameters and 9 actions, this is insufficient for an agent to understand inputs and outputs.
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% (period, symbol, symbols, timeframe are described). The description adds the concept of 'crypto pairs' and 'batch analysis' but does not clarify parameter defaults or syntax (e.g., timeframe format). It adds marginal value beyond the schema, warranting a baseline score.
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 performs technical analysis on crypto pairs, listing specific indicators (RSI, MACD, Bollinger Bands, etc.) and analysis types (full composite, batch). This sets it apart from sibling tools like 'crypto_market' or 'backtest' which cover different domains.
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 offers no guidance on when to use this tool versus alternatives like 'backtest' or 'crypto_price'. It does not mention prerequisites, typical use cases, or when to avoid it. This lack of context makes it harder for an agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tradfi_newsBInspectFinnhub financial data: earnings calendar, general/crypto news, company profiles. Requires FINNHUB_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50, default 20) | |
| action | Yes | ||
| symbol | No | Stock symbol for company/earnings filter | |
| to_date | No | End date YYYY-MM-DD (earnings) | |
| from_date | No | Start date YYYY-MM-DD (earnings) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only discloses the API key requirement but does not state whether the tool is read-only, rate limits, or side effects. The lack of behavioral context beyond the prerequisite is a significant gap.
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, short and front-loaded with the tool's purpose. It is concise, though it could include more behavioral or parameter insight without being verbose.
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 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, how to use each action with symbol and dates, pagination, or default limit. The schema descriptions partially cover parameter details, but overall context for usage is lacking.
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%, so baseline is 3. The description adds value by mapping the listed data types to the action parameter's enum values (earnings, news, crypto_news, company) and implying usage of 'news' for general and crypto. This provides context beyond the schema's enum 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 clearly states the tool provides Finnhub financial data: earnings calendar, general/crypto news, and company profiles. It identifies the verb (provides) and the resource (Finnhub data). However, it does not distinguish this tool from the sibling 'news_feed', and the tool name 'tradfi_news' could mislead about the inclusion of crypto 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?
The description only mentions a prerequisite (requires API key) but provides no guidance on when to use this tool versus sibling tools like 'news_feed' or 'backtest'. There is no mention of what actions are appropriate for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
social_trendingBInspectSocial media trending lists: Douyin, Weibo, Bilibili, Zhihu, Baidu, GitHub, Toutiao, 36Kr, CSDN, and more. Three-provider failover.
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'three-provider failover' as a behavioral trait, adding value beyond schema. However, does not disclose output format, rate limits, 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?
Two efficient sentences, front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with well-documented schema, but lacks details on output format and how the failover works, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. Description lists platforms redundantly but includes 'and more' hinting at extensibility, adding minimal value 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?
Description clearly states it provides social media trending lists from multiple platforms, distinguishing it from financial siblings. Lacks an explicit verb like 'retrieve' or 'list' but purpose is unmistakable.
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, though siblings are in different domains. Could mention scenarios like monitoring social trends or news aggregation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.