sol-mcp provides 4 clearly named tools with strong action verbs (get_, batch_) and detailed descriptions. All tools have proper input schemas with type definitions and parameter descriptions. Tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) are consistently applied. However, output schemas are not formally documented, responses are returned as free-text strings rather than structured objects. Error handling returns text-based errors without guidance on recovery actions or error classification. The codebase shows good naming discipline and parameter validation, but lacks the structured output and sophisticated error recovery patterns expected of production tools. Descriptions range from 120-250 chars (baseline: 194), which is appropriate for LLM parsing.

• Refactor tool responses to return structured JSON objects instead of concatenated strings. Example: `{ risk_score: 45, risk_label: 'MEDIUM', holder_count: 2500, liquidity_usd: 125000, whale_concentration_pct: 8.3, flags: ['low_liquidity'] }` instead of a text blob. This enables downstream tools to extract fields reliably.
• Enhance error responses with classification and recovery hints. Example: `{ isError: true, error_type: 'retryable', message: 'Risk API timeout (500)', recovery_hint: 'The upstream service is temporarily unavailable. Retry in 30 seconds or use batch_token_risk to check multiple tokens at once.' }` instead of plain text.
• Document batch_token_risk's per-item error handling explicitly. If the Promise.allSettled approach returns mixed success/failure results, include a summary: `{ total: 10, succeeded: 8, failed: 2, results: [...], errors: [{mint: 'ABC...', reason: 'not found'}] }`.
• Add pagination guidance to tool descriptions if result limits are imposed. For example: 'Returns up to 100 results. Use cursor parameter for pagination.' or 'For bulk analysis of >10 tokens, use batch_token_risk.' Also specify what happens if results exceed the limit (truncated vs. error).
• Include dependency hints in tool descriptions to guide multi-step plans. For example, in get_momentum_signal description, add: 'Often paired with get_token_risk to validate low-risk + strong buy signals.' This helps LLMs compose tools more intelligently.
• Document the 'windows' response structure in get_momentum_signal output. The code shows m5, h1, h6 with buys/sells/ratio fields, but these are hardcoded in the response string. Publish a formal schema so LLMs know what to expect.