wiki-mcp demonstrates solid tool design with 14 well-named, verb-prefixed tools (search, get_note, write_note, etc.). All tools have descriptions (avg ~180 chars, within 10-1024 baseline). Input schemas are present and typed for all tools. However, output schemas are undocumented, responses are inferred from code inspection, not declared in tool definitions. Error handling is minimal: most tools return {'error': str(e)} without recovery guidance. Parameter descriptions are present but sometimes generic (e.g., 'relative path' lacks format/constraint detail). Write operations (write_note, update_note, append_section) lack confirmation/dry-run patterns. Tool composition is strong: search→get_note→backlinks forms a natural chain with proper ID threading.

• Document output schemas for all tools. Add a 'Returns' section to each tool docstring specifying field names, types, and meanings. E.g., search returns {query: str, count: int, hits: [{path: str, title: str, snippet: str, rank: float}]}.
• Add dry-run support to write_note and update_note. Accept a 'dry_run: bool' parameter; when true, lint and return the would-be result without writing. Agents can preview before committing.
• Enhance error messages with recovery guidance. E.g., 'Note not found at path. Try search(query) to find it, or list_tags() to explore available notes.'
• Convert 'type' parameter in write_note to an enum constraint in the schema instead of relying on description text. Same for 'folder', validate against known folders or document the constraint.
• Add offset/limit pagination to list_tags() and stubs(). Return {count: int, total: int, offset: int, limit: int, items: [...]} to support large vaults.