Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This MCP server has 10 tools with basic structure but significant gaps in definition quality. Tool names follow verb_noun convention (getCryptocurrencies, searchCryptocurrencies, etc.), which is good. However, descriptions are very brief (15-65 chars), falling below the 194-char baseline average for production tools. Parameters lack depth: most have minimal descriptions and no constraints (enums, ranges, formats). No output schemas are documented, critical for helping LLMs understand what data to expect and how to chain calls. Error handling is not visible in the tool definitions. The server appears to be a REST+Express implementation exposing CRUD operations on crypto data and watchlists, but the definitions do not meet production-grade clarity standards. Tools 1, 3, 5, 8, 10 are READ_ONLY; tools 4, 6, 7, 9 are WRITE, but no confirmation/dry-run patterns are evident for destructive operations.
Tools (10)
createPriceAlertwrite50/100
Create a price alert for a cryptocurrency with specified alert type and target value
createWatchlistItemwrite50/100
Add a cryptocurrency to user's watchlist
deletePriceAlertwrite50/100
Delete a specific price alert by ID
getCryptocurrenciesread only50/100
Fetch list of cryptocurrencies with optional limit parameter
Descriptions are too brief and lack contextual clarity. Average 37 chars vs 194-char production baseline. Descriptions like 'Fetch list of cryptocurrencies with optional limit parameter' (60 chars) do not explain WHEN to use vs similar tools, WHAT data is returned, or dependencies.
No output schemas documented. LLMs cannot infer what fields exist in responses (e.g., does getCryptocurrencies return symbol, price, market_cap, or all?). This blocks chaining and forces discovery calls.
Expand tool descriptions to 50 - 200 chars. Template: '[WHAT] Get a list of cryptocurrencies with optional filtering. [WHEN] Call this to discover available assets before searching or creating alerts. [RETURNS] Array of {id, symbol, name, current_price, market_cap}. [PREREQUISITE] None; no auth required.'
Parameter descriptions are minimal. 'Optional limit for number of cryptocurrencies to return' (58 chars) lacks constraints: is limit 1-1000? 1-100? What happens if omitted? Similar gaps on alertType enum (price_above, price_below, percentage_change), the description lists values but does not explain behavioral differences.
No error handling patterns documented. What happens if cryptoId does not exist? If alert creation fails due to invalid targetValue? LLMs receive no guidance on recovery (retry, ask user, lookup first).
Parameter 'targetValue' in createPriceAlert is typed as string but represents a numeric price or percentage. This causes type confusion, should it be a number? What format for percentage? Description does not clarify.
getWatchlist and getPriceAlerts have empty input schemas ({}). No pagination parameters visible. If a user has 500 alerts, will all be returned? Risk of context overflow and degraded LLM reasoning.
getWatchlistgetPriceAlerts
Add confirmation patterns for WRITE operations. Example createPriceAlert description: 'Creates a price alert for a cryptocurrency. Note: This triggers notifications. Use getPriceAlerts() first to check existing alerts and avoid duplicates.'
Document error responses. Example: 'If cryptoId is invalid, returns {error: 'Crypto not found', code: 'CRYPTO_NOT_FOUND', suggestion: 'Call searchCryptocurrencies() to find a valid ID.}'
Add parameter for cryptoId type clarification. Accept both system ID (e.g., 'BTC') and human-friendly name (e.g., 'Bitcoin'). Describe: 'Cryptocurrency ID (e.g., BTC) or name (e.g., Bitcoin). System searches by ID first, then name.'
Rename targetValue to targetPrice for price alerts and targetPercentage for percentage alerts to avoid type confusion. Or use a single targetValue with description: 'Target value as a decimal number. For price_above/price_below: USD value (e.g., 45000). For percentage_change: percentage (e.g., 5 for 5%).'
Add a tool to list available cryptocurrencies with metadata (id, symbol, name, current_price) to help agents discover valid IDs. This prevents wasted lookup calls.