Loading ToolBench
A local-first note-taking app MCP server that provides tools for searching, reading, listing, and managing notes with backlink tracking and semantic search capabilities.
Moldavite MCP server provides 7 tools with clear verb-based naming and generally adequate descriptions. However, there are critical gaps in schema documentation, parameter descriptions, and error handling. Tool names are well-chosen (search_notes, read_note, list_notes, get_backlinks, create_note, append_to_daily_note, write_note) and follow verb_noun conventions. Descriptions are present but vary in quality and specificity. The most significant issue is that while input schemas are visible in the source (with parameter names, types, and basic descriptions), they lack critical validation details, constraints, and error recovery guidance. No output schemas are documented. The server implements write operations (create_note, append_to_daily_note, write_note) but lacks confirmation patterns or comprehensive error guidance for these destructive operations.
Append content to a daily note, creating it if it doesn't exist. Uses ISO format date (YYYY-MM-DD).
Create a new note at the specified path with optional initial content. Returns error if the note already exists.
Get all notes that link to a specified target note, including the linking note's title and link context.
List all notes in the forge, optionally filtered by folder. Returns paths and lock status.
Read the full content of a note at a specified path, including a content hash for conflict detection.
Search notes by keyword or semantic similarity. Returns results in either semantic or keyword mode.
No documented output schemas for any tool. LLMs cannot plan downstream operations without knowing what fields to expect from responses.
Write operations (create_note, append_to_daily_note, write_note) lack confirmation/dry-run patterns and comprehensive error recovery guidance. Agents could accidentally lose data without multi-step confirmation.
Parameter descriptions lack explicit validation constraints. 'limit' in search_notes states default 20 and clamping 1-100, but this critical constraint is buried in description text rather than expressed as min/max schema properties. No regex patterns or length limits documented for path parameters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Overwrite the content of an existing note, with optional conflict detection via contentHash.
No error handling guidance. Tools do not specify what errors are retryable, user-fixable, or fatal. Error responses would not guide LLMs to recovery actions (e.g., 'note not found' should suggest list_notes to discover available notes).
Tool composition assumes agent knows internal folder structure. list_notes accepts optional 'folder' parameter but no discovery tool explains the folder hierarchy. Agents cannot call list_notes to discover available folders, they must infer structure from context.
The 'contentHash' parameter in write_note for conflict detection is underdocumented. How is the hash computed? Is SHA256 confirmed in source or only inferred? What does a mismatch error look like? Agents cannot use this feature safely without clear specification.