Loading ToolBench
Modern MCP Server with DuckDuckGo Search and comprehensive crypto, DeFi, NFT, and traditional finance tools
This server defines 20 tools with significant structural quality issues. Tool schemas are present and well-formed (JSON Schema with types), but naming conventions are inconsistent, descriptions are often generic, parameters lack proper constraints, and error handling is not visible in the source. Many tools expose API keys as parameters (security risk), and several share overlapping responsibilities (e.g., duckduckgo_search vs web_search, crypto_price vs solana_token_analysis). Output schemas are not documented. The server relies heavily on external APIs (CoinGecko, Alpha Vantage, OpenSea, LunarCrush, Apollo) but does not show error recovery patterns or actionable error messages. Tool composition is weak, there are multiple ways to accomplish the same task (search, analyze crypto) without clear disambiguation. Average parameter count is 5.5 per tool, reasonable, but most lack validation constraints or format specifications. Descriptions average ~80 chars, below the 194-char production baseline, and many are under 50 chars (e.g., 'Search the web', 'Get cryptocurrency price information'). No tool shows evidence of documentation for return types, pagination, or chaining fields required by downstream tools.
Access Aave DeFi protocol data
Access financial data, technical indicators, and fundamental data from Alpha Vantage API
Access stock market data, ETFs, and traditional finance data from Alpha Vantage API
Access Apollo.io business intelligence data including people search, organization search, job postings, company information, and news articles.
Calculate APY for various yield strategies
Access CoinDesk market data, news, and price indices
Get cryptocurrency news and updates
API keys exposed as tool parameters. duckduckgo_search, crypto_price, lunarcrush, coindesk, pumpnews, pumpfun, nft_marketplace all accept api_key parameters. Credentials should NEVER appear in tool inputs, they must be injected server-side. Agent traces log all parameters, exposing secrets to logs, prompt history, and storage systems.
Duplicate or overlapping search tools. duckduckgo_search and web_search both perform general web search with near-identical parameters (query, max_results, region, search_type). LLMs cannot disambiguate when to use one vs. the other. Consolidate into a single search tool or clearly differentiate by source/ranking strategy.
Multiple overlapping crypto analysis tools without clear disambiguation. crypto_price, market_analysis, lunarcrush, solana_token_analysis, and alpha_vantage all provide price/market data with different APIs and parameters. Tool names do not signal which to use when (e.g., is market_analysis for technical TA or sentiment? Does lunarcrush include price?). Descriptions under 50 chars do not clarify decision logic.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Get cryptocurrency price information
Access DeFi protocol data and analytics
Search the web using DuckDuckGo
Access Jupiter DEX aggregator for Solana
Access LunarCrush cryptocurrency analytics, social sentiment, and market intelligence data
Perform cryptocurrency market analysis
Access NFT marketplace data and analytics
Track and manage cryptocurrency portfolios
Access PumpFun token launching and analysis data
Access cryptocurrency news and trending information
Access Raydium DEX data for Solana
Access Solana token data, trending tokens, market analysis, and pump detection using CoinGecko API
Search the web
Generic, undersized descriptions. 'Search the web' (19 chars), 'Get cryptocurrency price information' (36 chars), 'Get cryptocurrency news and updates' (35 chars), 'Access Aave DeFi protocol data' (30 chars). These provide minimal context for LLM selection. Production baseline is 194 chars avg. Descriptions should explain WHAT the tool does, WHEN to use it (vs. similar tools), and any key constraints or prerequisites.
No documented output schemas or return types. The rubric requires tools to document what fields and structure they return so LLMs can plan downstream calls and extract data. Without documented returns, agents cannot reliably chain tools (e.g., does search return coin_ids that market_analysis accepts? Does get_trending_solana_tokens return fields that solana_token_analysis needs?). No evidence of pagination, limits, or next_cursor in visible code.
Incomplete parameter constraints and descriptions. Most numeric parameters (principal, rate, time_period, limit, max_results) lack min/max bounds. Enum parameters (e.g., analysis_type, calculation_type, action) are present but many string parameters (coin_id, token, symbol) lack format/pattern guidance. Parameters like 'amount' in jupiter accept strings but lack specification of format (decimal vs. integer vs. lamports). Descriptions do not explain ranges or formats (e.g., 'time_period in years' is unclear, is 1.5 valid? Does it support fractional years?).
Pumpfun tool has minimal schema definition. Action parameter is required but no enum values defined, what actions are supported? Description 'Access PumpFun token launching and analysis data' (37 chars) is too vague. This tool is effectively non-functional without knowing valid actions.
No visible error handling or recovery patterns. Source code does not show error categorization, actionable error messages, or recovery guidance. Tools calling external APIs (CoinGecko, Alpha Vantage, OpenSea, LunarCrush, Apollo) can fail for many reasons (rate limit, API down, invalid key, malformed response) but no evidence of handling these with guidance for the LLM. Agents have no way to know: Is this retryable? Should I ask the user? Or is it fatal?
No tool composition support. Many tools require user lookups or disambiguation that should be handled by discovery tools. For example, apollo search_people returns people, but update_person is not present. Raydium get_tokens returns tokens but no tool accepts them as input to subsequent calls. Chain dependencies are not documented.
Inconsistent parameter naming for similar concepts. crypto_price uses 'coin_id', but solana_token_analysis uses 'token_id'. market_analysis uses 'coin_id' but jupiter uses 'input_mint' and 'output_mint'. No consistent pattern for resource identifiers across tools, forcing LLMs to reason about field mappings and increasing errors.
No documented dependencies between tools. portfolio_tracker references 'coin_id' but does not specify that valid coin_ids must come from crypto_price or market_analysis. aave references 'pool_address' but no tool returns pool_address fields. Missing dependency hints force agents into discovery loops or guessing.