Model Context Protocol (MCP) server for TiddlyWiki - enables AI assistants to interact with your wiki.
The TiddlyWiki MCP server defines 5 tools with reasonable naming (verb-noun format) and parameter schemas. However, several quality gaps prevent a higher score: (1) Tool descriptions are adequate but brief (avg ~80 chars), lacking the 10-200 char optimization window guidance; (2) Parameter descriptions are minimal and lack constraints (enums, ranges, format specifications); (3) Output schemas are not explicitly documented in the server definition; (4) No tool annotations (readOnlyHint/destructiveHint) despite having tools with clear risk profiles; (5) Error handling guidance is absent. The test file confirms tools work but reveals incomplete schema documentation. Naming is consistent (read_, list_, search_, write_, delete_) and self-documenting. Per-tool analysis follows.
Delete a tiddler from the wiki
List all tiddlers or filter them using a TiddlyWiki filter expression
Read a tiddler and return its content and fields
Search for tiddlers containing specific text
Create or update a tiddler with the specified content and fields
No tool annotations present: readOnlyHint for read/list/search tools, destructiveHint for delete_tiddler. LLMs cannot infer mutation risk without explicit markers.
Output schemas are not documented. Callers cannot know field structure, types, or required vs optional fields. E.g., read_tiddler returns JSON with .title/.text/.fields, but no formal schema is visible.
Parameter descriptions lack constraint guidance: no enums for type field (valid MIME types?), no min/max for limit, no format specs for title. Format guidance like '(2-100 alphanumeric + spaces)' is missing.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 63 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 11 | - | v1 |
No error handling patterns documented. Tools can fail (non-existent tiddler, invalid type field, permission denied) but no guidance on recovery: which errors are retryable? Should the LLM ask the user or try a different approach?
write_tiddler combines CREATE and UPDATE semantics but does not distinguish them in the description. Agents cannot reason about idempotency or retry safety. Should be split or explicitly state: 'Creates or updates; idempotent if same title.'
delete_tiddler lacks confirmation/dry-run pattern. Destructive operations should support a verification step to prevent accidental deletion. Consider adding a 'confirm' param or separate 'preview_delete' tool.
list_tiddlers description mentions 'optional' filter but does not document what happens when filter is omitted (returns all? system tiddlers included by default?). Edge cases must be explicit.