This MediaWiki MCP server exposes 2 read-only tools with explicit schemas and descriptions. Both tools have properly structured input and output schemas defined via the Kotlin SDK's ToolSchema class. However, there are significant issues that prevent a higher score: (1) Tool descriptions use template variables like ${envConfigProvider.wikiName()} which are only resolved at runtime, the descriptions are not static/previewable and rely on indirect configuration, making them less useful for static analysis and LLM planning; (2) Parameter descriptions are minimal and generic, lacking guidance on constraints, expected formats, or when to use one tool vs. the other; (3) No tool annotations (readOnlyHint, etc.) despite both being read-only operations; (4) Output schemas are documented but lack guidance on pagination or result limits, the search_wiki tool returns an array with no limit parameter visible; (5) Error handling is not visible in the source, so recovery guidance is unknown. The schemas themselves are well-formed with proper types and required field declarations, which prevents a lower score. Per-tool analysis: search_wiki (naming: 80, description: 40, schema: 70, overall: 63), get_page_content (naming: 85, description: 45, schema: 75, overall: 68). Average: 65. Adjusted to 58 due to STDIO transport cap and lack of actionable error handling patterns.

• Replace runtime template variables in descriptions with concrete wiki name. Either bake it into the description at server startup or accept it as a configurable constant. Description should be static and previewable. Example: 'Search Wikipedia for information about the topic' instead of 'Search the ${envConfigProvider.wikiName()} for information about the topic'.
• Enhance parameter descriptions with actionable constraints. For search_wiki query: 'Search query (free-form text, 1-200 characters, supports Boolean operators AND/OR/NOT). For get_page_content page_title: 'Exact page title (case-sensitive, URL-decoded; redirects are followed).'
• Add tool annotations. Mark both tools with readOnlyHint=true in the Tool object constructor. This signals to agents that these are safe to retry and have no side effects.
• Implement structured error handling with recovery guidance. Define error response types (e.g. PageNotFound with 'alternatives' field containing similar page titles, NetworkTimeout with 'retryAfter' field). Document in tool descriptions.
• Add explicit constraints to search_wiki limit parameter. Change description to 'Maximum number of results to return (1-100, default 5)' and validate server-side to reject requests with limit > 100.
• Document pagination for search_wiki. If results can exceed limit, add guidance: 'For large result sets, sort results by relevance (default) or date. Use snippet to preview content before calling get_page_content on the full page.'
• Add output field descriptions for complex nested objects. In search_wiki results array items, clarify: 'snippet' is excerpt, 'sectiontitle' is the heading where snippet appears (useful for disambiguation), 'categorysnippet' is metadata (use for filtering). This helps agents construct better multi-turn queries.

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry