Zero-dependency MCP server that exposes a wikikit wiki (folder of Markdown files with frontmatter) to any MCP client. Supports listing pages, reading pages/sections, searching, and viewing recent updates.
Wikikit exposes 5 well-named, read-only wiki tools with clear descriptions and proper input schemas. All tools follow verb_noun naming (wiki_*) and include descriptions (avg 140 chars, within baseline 34 - 392). Schemas are present and typed. However, parameter descriptions are sparse: 'slug' in wiki_read_section lacks a description; 'page_type' descriptions reference '[types]' placeholder instead of actual enum values; output schemas are undocumented. Error handling is basic (returns error objects but no recovery guidance). No tool annotations (readOnlyHint, etc.). Composition is sound, tools chain naturally (list → read/search → section). Missing: pagination for wiki_list_pages and wiki_search (no limit param on list; search caps at 25 but no offset/cursor); output field documentation.
List all wiki pages (slug, title, type, status, last_verified, summary). Use first to discover what exists before reading or searching.
Read one full wiki page by slug, including metadata and sources.
Read a single section of a page by heading (case-insensitive substring). Cheaper than wiki_read_page — prefer it when you need one section.
Pages verified/updated within the last N days (default 14) — the freshness view.
Keyword search across titles, tags, summaries, headings, and bodies. Returns ranked matches with snippets.
Output schemas undocumented. LLMs cannot predict response structure (e.g., wiki_read_page returns {slug, title, type, status, last_verified, summary, sources, tags, body} but this is not declared in tool spec). Agents must infer field names from examples, risking misuse.
Parameter descriptions incomplete. 'slug' in wiki_read_section has no description (only 'Page slug' in wiki_list_pages). 'page_type' descriptions reference '[types]' placeholder instead of actual enum values (e.g., 'one of [types]' should be 'one of: entity, process, policy'). LLMs cannot validate input without concrete constraints.
No pagination on wiki_list_pages. Tool returns all pages in a single response with no limit or offset. For large wikis (100+ pages), this bloats context and wastes tokens. Should accept limit (default 20, max 100) and offset/cursor.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. wiki_read_page returns {'error': 'no page with slug X. Use wiki_list_pages to see slugs.'}, good. But wiki_read_section returns {'error': '...', 'available_headings': [...]}, inconsistent. No guidance on retryability or next steps for other errors.
No tool annotations. Tools lack readOnlyHint (all are read-only), idempotentHint (all are idempotent). Clients cannot optimize caching or retry logic without these hints.