Loading ToolBench
Coinmarket MCP Server that provides cryptocurrency data from CoinMarketCap API
This server has critical definition quality gaps. Both tools lack parameter descriptions entirely, which is a hard REQUIREMENT per the rubric (100% of A+ tools have param descriptions). Tool descriptions are present but extremely brief (15-30 chars). Input schemas exist but lack the critical detail layers needed for LLM reasoning. The get_quotes tool accepts parameters but provides no guidance on what 'slug' vs 'symbol' mean, when to use each, or what format they expect. No output schemas are documented. Error handling provides no recovery guidance. The resource implementation (coinmarket://cryptocurrency/listings and /quotes) is present but underdocumented and poorly integrated with the tools.
Get latest cryptocurrency listings
Get cryptocurrency quotes
CRITICAL: All parameters lack descriptions. get_quotes accepts 'slug' and 'symbol' parameters with no explanation of what each means, when to use each, what format is expected, or whether both can be passed simultaneously.
CRITICAL: Tool descriptions are under 20 characters (hard floor violation). 'Get latest cryptocurrency listings' (30 chars) and 'Get cryptocurrency quotes' (24 chars) are too terse to guide LLM selection. They do not explain WHEN to use each tool, WHAT distinguishes them, or WHAT data is returned.
CRITICAL: No output schemas documented. LLMs cannot know what fields to expect from get_currency_listings or get_quotes responses. This prevents downstream tool composition and forces the LLM to parse unstructured JSON responses at runtime, increasing errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
HIGH: Parameter validation logic is missing. get_quotes requires either slug OR symbol but does not validate this in the tool definition or error messages. The function accepts None for both, and the API will fail silently or return unexpected results. The description must state: 'Exactly one of slug or symbol is required.'
HIGH: Error handling provides no recovery guidance. Exceptions are caught and re-raised as RuntimeError with a generic message (e.g. 'Failed to fetch listings data: {e}'). The LLM receives no actionable next steps, should it retry? Call a different tool? Ask the user?
HIGH: No result limits documented or enforced. The server returns raw API responses with potential for very large result sets. The tool description does not state that results are capped (e.g. 'Returns top 5 cryptocurrencies' for listings). Unbounded results can exhaust context windows.
MEDIUM: Naming ambiguity. 'get_quotes' does not clarify that it is cryptocurrency quotes specifically, nor that it returns price/market data. A tool called 'get_quotes' could mean stock quotes, insurance quotes, or anything else. Consider 'get_crypto_quotes' or 'get_price_quotes'.
MEDIUM: Parameters use natural names (slug, symbol) without type information. The schema declares type: string, but does not specify length limits, pattern constraints, or case sensitivity. 'slug' in CoinMarketCap API is a URL-friendly name like 'bitcoin', this is not documented.
MEDIUM: Resources are defined (coinmarket://cryptocurrency/listings, /quotes) but are disconnected from the tools and lack descriptions. The resource handler duplicates tool logic. Users and LLMs will be confused about whether to call the tool or read the resource.