Server has 10 tools with consistent naming (all start with 'get_') and reasonable descriptions (100-200 chars). However, most tools accept NO parameters (empty input schemas), which severely limits their utility and schema documentation. Parameter descriptions are present where parameters exist, but the lack of input flexibility is a major gap. Output schemas are not explicitly documented in the source. Error handling is minimal, no recovery guidance or actionable error messages visible. Tools follow a read-only pattern well but lack the sophistication expected of production-grade agents.

• Add optional parameters to parameterless tools: get_bitcoin_price could accept 'source' (coinbase|kraken|both), 'include_spread' (boolean). get_network_summary could accept 'include_mining_details' (boolean). This enables agents to customize queries without multiple tool calls.
• Document output schemas explicitly in tool descriptions. E.g., 'Returns: {price: number (USD), sources: [{name: string, value: number, timestamp: ISO8601}], spread: number (percent)}'. Agents need to know what fields to expect.
• Add error handling guidance: 'If cross-source verification fails (price spread > 5%), returns best-effort average with confidence: low. Retry after 30s or use single source.' This tells agents how to handle degraded responses.
• Simplify get_bitcoin_mean_reversion_index description to: 'Get Bitcoin mean reversion index (BMRI), a metric comparing current price to historical averages. Use to assess if Bitcoin is overbought/oversold. Returns zone classification (accumulation|distribution|neutral) and supporting metrics.'
• Add pagination/limit parameters to tools returning lists (e.g., get_network_summary could accept 'max_sources' to limit cross-source calls). Document result limits in descriptions (e.g., 'Returns up to 10 price sources').