Server provides 9 read-only tools with consistent naming (pythia_* prefix) and reasonable descriptions (avg 150 chars). All tools have descriptions meeting the 10-1024 char baseline. However, most tools accept zero or one parameter with minimal schema detail. Input schemas are present but sparse: pythia_list_tokens, pythia_health_check, pythia_contracts, pythia_pricing, pythia_events_info, pythia_subscribe_info, pythia_visions_info have empty input objects ({}), while pythia_token_feeds and pythia_vision_history accept only engine_id as a string with basic description. No output schemas are documented in the source code, LLMs cannot predict response structure. Parameter descriptions lack format constraints, ranges, or enum values. Error handling is not visible in the tool definitions. All tools are read-only (no state mutation), which reduces risk but also limits utility.

• Document output schemas for all tools. Define response structure as JSON Schema (e.g., pythia_list_tokens returns {tokens: [{symbol, engine_id, status, uptime_30d, sources}], stats: {tokens, total_indicators}}). This enables LLMs to plan downstream calls and extract fields reliably.
• Add enum constraints to engine_id parameters. Replace 'e.g. bitcoin, solana, aave' with a formal enum derived from pythia_list_tokens output. This prevents hallucinated token IDs and makes the tool self-documenting.
• Enhance discovery tool descriptions with workflow guidance. E.g., 'Call this first to list available tokens before requesting feeds. Returns token symbols and engine IDs needed for pythia_token_feeds.'
• Implement structured JSON output instead of formatted strings. Return {tokens: [...], stats: {...}} instead of a formatted table. This reduces parsing errors and token waste.
• Add error handling documentation. Specify what happens on API timeout, invalid engine_id, or service unavailability. Include recovery hints: 'If engine_id is invalid, call pythia_list_tokens to see available IDs.'