Server provides 4 well-structured read-only tools with complete JSON schemas and reasonable descriptions. All tools have proper input schemas with typed parameters and enums where appropriate. Descriptions are adequate (100-200 chars) but lack actionable guidance on when to use each tool vs. alternatives. Parameter descriptions are present but generic. Output schemas are documented in code but not exposed to the LLM. Error handling is minimal, no recovery guidance or categorization. Naming follows verb_noun convention correctly. No security concerns (read-only, no secrets). Composition is sound, each tool has one responsibility and outputs chain naturally.

• Add outputSchema to each tool definition documenting the response structure. Example: 'Returns an object with fields: id (integer), question (string), outcomes (array of {outcome: string, probability: string, price: number}), volume (object with total, 24h, 1w, 1m), liquidity (string), active (boolean), end_date (ISO 8601 string).'
• Expand parameter descriptions with constraints and guidance. E.g., 'market_id: Numeric market identifier (preferred if known). market_slug: URL-friendly market name (e.g., "will-bitcoin-hit-100k-in-2024"). If both provided, market_id takes precedence.'
• Add error recovery hints to tool descriptions. E.g., 'If market not found, try search_markets() with a partial query term. If API timeout, retry after 2 seconds.'
• Document valid tag values for get_trending_markets. Either enumerate them ('politics', 'crypto', 'sports', 'entertainment') or add a separate list_market_tags() discovery tool.
• Add per-tool guidance on selection. E.g., 'Use search_markets to find markets by keyword. Use get_trending_markets to discover popular markets without a specific query. Use get_market_details for full odds and metadata on a known market. Use get_event_details to see all related markets grouped under an event.'