MCP server for building and maintaining LLM-powered knowledge wikis
This server has 8 well-defined tools with consistent naming patterns (all start with 'wiki_') and reasonable descriptions (70-150 chars). However, parameter descriptions are sparse or missing, schemas lack depth, and output structures are undocumented. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible in the source. Error handling guidance is minimal. The codebase shows solid engineering (TypeScript, tests, linting), but the tool definitions fall short of production-grade agent integration standards. Baseline: 549 production tools average 194 chars for descriptions and 72 chars per param annotation; this server averages ~100 chars for descriptions and provides minimal param guidance.
Create a new wiki page with title, content (including frontmatter), and optional page type
Delete a wiki page and report any broken links
Read a raw source document and return its content with context for wiki processing
Create a new wiki vault with folder structure and default config
Health-check the wiki: find orphan pages, broken links, missing frontmatter, stale index entries
Read a wiki page by title or path
Search across wiki pages using text or semantic search
Output schemas completely undocumented. No tool returns a documented structure, LLM cannot know what fields to extract for downstream tool calls.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) absent from tool definitions. Risk metadata (READ_ONLY, WRITE, DESTRUCTIVE) exists in source comments but is not serialized into the MCP tool registration.
Parameter descriptions sparse or missing. wiki_init's 'name' param has no description; wiki_read_page params lack descriptions; wiki_update_page content param lacks guidance on frontmatter handling; wiki_search max_results lacks constraint documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Update an existing wiki page with new content
No numeric constraints on parameters. wiki_search max_results is unbounded; wiki_init path and wiki_read_page title/path accept any string. LLMs will pass invalid/absurd values without validation guidance.
No error handling guidance in descriptions. Tools do not explain what to do if path invalid, vault missing, page exists, or write fails. No recovery patterns offered.
wiki_delete_page and wiki_update_page lack idempotency declarations and confirmation patterns. Destructive and modifying tools should either support dry-run/confirmation or explicitly state idempotency guarantee.
wiki_read_page declares title and path as optional and independent, but semantics unclear. Rubric requires explicit mutual-exclusivity documentation ('one or both required').
wiki_search lacks pagination and result limits clarity. Description mentions 'max_results (default: 10)' but does not state upper bound or explain when to paginate for large result sets.