The server defines 6 tools with complete schemas and basic descriptions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameter descriptions are present but minimal. Output schemas are not documented, LLMs must infer what fields will be returned. Tool naming is clear and verb-driven, but lacks composition guidance for multi-step workflows. Error handling exists but responses are not actionable for recovery. No tool annotations present.

• Document output schemas for each tool. Add a 'returns' field in code comments and/or publish an OpenAPI spec showing response structures. Example for search_wiki: 'Returns {query, totalResults, results: [{title, size, wordcount, timestamp, snippet, url}]}'.
• Expand tool descriptions to 100-150 chars with LLM-selection hints. Example: 'Search for articles by keyword. Use this FIRST to find page titles, then call get_page_content for full article text.' Clarify when to use get_page_info (metadata only) vs get_page_content (full text) vs get_page_sections (structure).
• Add min/max constraints and format guidance to numeric parameters. Example: 'limit' should be 'Number of results to return (default: 10, min: 1, max: 50). Requests over 50 will be capped.'
• Enhance error messages with recovery hints. In getPageContent error handling, replace 'Page not found' with 'Page "${title}" not found. Try search_wiki("${title}") to find the correct title.'
• Add tool annotations to schema definitions. Set readOnlyHint: true for all tools to signal to clients that these are safe to retry and do not modify state.
• Document workflow guidance in descriptions. Add a comment in setupToolHandlers() noting the typical flow: 'Typical workflow: search_wiki() → get_page_sections() → get_page_content(section=N) for focused retrieval.'
• Specify timeout and result-size limits in descriptions. Document that limit parameters cap at 50 (search_wiki, get_recent_changes) and 20 (get_categories). Mention default timeouts for external API calls.