12 tools with consistent verb-noun naming (get_*, search_, check_) and basic Zod schemas. All tools have descriptions (10-60 chars, below the 50-200 char LLM-optimized baseline). Input schemas present but minimal, single string parameters with descriptions. No output schemas documented. Error handling returns raw error messages without recovery guidance. No pagination, no result limits, no structured output guidance. Composition is sound (each tool does one thing), but descriptions lack context on when to use each tool vs. alternatives (e.g., get_summary vs get_content). No parameter constraints (enums, ranges). Baseline: 549 production tools average 194 chars for descriptions; this server averages ~35 chars.

• Expand tool descriptions to 100-200 chars. Include WHEN to use each tool: 'get_summary: Quick overview (1-2 paragraphs). Use when you need a brief introduction. For full text, use get_content.' Distinguish get_summary vs get_content vs get_html explicitly.
• Document output schemas for each tool. E.g., get_summary returns {title, extract, url, thumbnail_url}; get_links returns {links: string[]}. Include field types and whether results are paginated.
• Add pagination to list-returning tools (get_links, get_references, get_images, search_pages). Accept limit (default 20, max 100) and offset/cursor parameters. Return total_count and next_cursor.
• Enhance error responses with recovery guidance. E.g., 'Page "Phyton" not found. Did you mean: Python, Phyton (disambiguation)? Try search_pages("python") to find similar pages.' Classify errors as retryable vs user-fixable.
• Add input validation with clear error messages. E.g., if page is empty, return 'page parameter required, provide a Wikipedia page title (e.g., "Albert Einstein").' Validate page length (1-255 chars) and reject special characters that break Wikipedia URLs.