Progressive-retrieval MCP server for Wikipedia
Wikipedia MCP server has reasonable tool coverage with 5 well-named read-only tools covering Wikipedia's core functionality. Tool names follow verb_noun convention (search_articles, get_summaries, get_toc, get_section, get_page). However, parameter descriptions are minimal or missing, output schemas are not documented, and error handling lacks actionable guidance. The server.py source shows solid naming discipline but incomplete schema documentation and sparse parameter descriptions. Per the rubric baseline (90% of A+ tools have docstrings on ALL params; 100% document return types), this server falls short. Average tool score across 5 tools: 62 indicates fair quality with noticeable gaps in schema completeness and parameter documentation.
Get the full text content of a Wikipedia article
Get the full text of a specific section from a Wikipedia article
Get summaries for multiple Wikipedia articles
Get table of contents (sections) for a Wikipedia article
Search Wikipedia for articles matching a query
Output schemas not documented. Tools return results but LLMs have no specification of returned fields (structure, types, required fields). This forces LLMs to discover output structure via trial-and-error.
Parameter descriptions are minimal or missing. 'limit' in search_articles has a description ('Maximum number of search results to return (1-10, default 5)'), but other tools have sparse parameter docs. LLMs cannot infer 'section' means section title or index without explicit guidance.
No error handling guidance. Code shows RuntimeError and KeyError can be raised (e.g., 'Page not found' in get_toc), but the tool definitions do not document what errors can occur or how the LLM should recover.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
No pagination or result limiting documented for search_articles. Rubric pattern:paginated-result requires tools returning lists to accept limit/offset and document result caps. search_articles has a hardcoded max of 10 results, but get_page and get_section could return unbounded content and blow the context window. No documentation of this risk.
Tool descriptions lack 'WHEN to use' guidance. When should the LLM call it instead of a similar tool?' Search_articles and get_summaries both return article info, no guidance on when to use each. This forces LLM to guess and may lead to wrong tool selection.