CryptoSignals provides three tools with explicit, well-structured definitions visible in server.py. All three have descriptions (194 - 230 chars, aligning with the 194-char median), and parameters are typed. However, output schemas are not formally documented in code, they are implicit in the return statements. Input validation is minimal, and error messages lack recovery guidance. The domain focus (crypto volume anomaly detection) is clear and useful, but the server needs better error handling and explicit output schema documentation to reach B+ territory.

• Explicitly document output schemas in code. Use a tool registry or @dataclass definitions so schemas are machine-readable. Example: scan_all_tokens should declare it returns {signals: List[{symbol: str, price: float, change_24h: float, volume: int, market_cap: int, vol_mcap_ratio: float}], count: int, source: str}.
• Add structured error responses with recovery guidance. When analyze_token does not find a token, return {found: False, symbol, message, suggestion: 'Call scan_all_tokens() to see available tokens'}.
• Formalise parameter schemas via FastMCP's Input type annotation or explicit schema dicts. For analyze_token, use Input(symbol: Annotated[str, Field(description='Token ticker (e.g., BTC, ETH)', min_length=1, max_length=10)]) or similar.
• Add validation with actionable error messages. If symbol is longer than 10 chars, return {error: 'Invalid symbol length, must be 1-10 chars', received: symbol} instead of failing silently.
• Clarify result limits in descriptions. Update scan_all_tokens description to: 'Returns the top 50 tokens by volume-to-market-cap ratio. See get_anomaly_alerts() for high-confidence signals only.'
• If FastMCP supports tool annotations, declare all three tools as readOnly and idempotent so agents know they are safe to retry and do not modify state.
• Add per-tool error handling tests to verify that invalid inputs (symbol='', symbol='VERYLONGTOKEN') produce structured, helpful error responses.