MCP server for CoinStats API integration — stdio CLI + Cloudflare Worker. Provides comprehensive cryptocurrency data including prices, market caps, charts, portfolio management, and wallet/exchange integration.
CoinStats MCP demonstrates solid parameter coverage with extensive filtering options on get-coins, but suffers from weak tool descriptions, missing output schema documentation, and inconsistent parameter guidance. Naming is clear and action-oriented (all tools start with 'get-'). The server has 6 tools, all read-only, with comprehensive input schemas using Zod validation. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Parameter descriptions are present but inconsistent in quality, some are one-word, others lack format/range guidance. Output schemas are entirely undocumented, forcing LLMs to guess at response structure. Error handling is minimal and provides no recovery guidance.
Get the historical average price for a specific cryptocurrency based on its unique identifier and a specific date.
Get detailed information about a specific cryptocurrency based on its unique identifier.
Get chart data for a specific cryptocurrency based on its unique identifier, specifying different time ranges.
Get the historical price data for a specific cryptocurrency on a particular exchange.
Get comprehensive data about all cryptocurrencies: Price, market cap, and volume. Price changes (1h, 24h, 7d). Supply information. Trading metrics. Social links and metadata.
Get a list of supported exchanges.
Output schemas are completely undocumented. No tool specifies what fields are returned, data types, or nested structure. LLMs must guess at response shape, leading to parsing errors and misplaced field references in downstream calls.
Tool descriptions are generic and do not explain WHEN to use each tool vs similar alternatives. 'Get detailed information about a specific cryptocurrency' does not distinguish get-coin-by-id from get-coins with filters. LLMs cannot determine the optimal tool for a user's intent.
Parameter descriptions lack actionable guidance on format, range, and constraints. 'Unix timestamp' does not specify timezone or unit (seconds vs milliseconds). 'Exchange name' does not list valid exchanges or reference get-ticker-exchanges to discover them. Absence of constraints invites hallucinated values.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
get-coins has 36 parameters, many of which are filter variants (marketCap-greaterThan, marketCap-equals, marketCap-lessThan, etc.). This explosion of parameters creates cognitive load and increases the chance LLMs pass invalid combinations (e.g., both 'equals' and 'greaterThan' for the same field). Consider a single 'marketCap' parameter accepting an object or min/max syntax.
No error handling documentation. Tools do not specify what errors they return, how to recover, or whether errors are retryable. An LLM encountering 'coinId not found' does not know whether to retry, search for the coin first, or give up.
get-coins description mentions 'Price changes (1h, 24h, 7d)' and 'Social links and metadata' but these are not documented as output fields. LLMs expect all advertised features to be returned; missing fields cause parsing errors. Output schema must enumerate ALL fields.
No pagination guidance for get-coins. The tool accepts a 'limit' parameter (default 20) but does not document how to retrieve subsequent pages, what the maximum result count is, or whether results are always sorted consistently. This risks incomplete or misaligned queries when there are many results.