Loading ToolBench
mcp-obsidian has 4 well-structured tools with complete JSON schemas and clear descriptions. All tools follow proper verb_noun naming conventions (create_note, read_vault, update_note, delete_note). Descriptions are present and range from 80-150 characters, meeting baseline minimums (p10=34, p90=392). Tool schemas include typed parameters with descriptions. However, critical gaps exist: (1) Parameter descriptions lack detailed constraints (e.g., 'path' doesn't specify allowed characters or length limits); (2) No documented output schemas despite tools returning structured data; (3) Error handling is implicit, no guidance on what errors LLM should expect or how to recover; (4) update_note combines two different actions ('replace' and 'patch') in one tool, violating single-responsibility; (5) read_vault is complex with conditional parameters based on 'action' enum, but dependencies are underdocumented; (6) delete_note lacks safety mechanisms (no dry-run, no confirmation pattern). The 'by' parameter in read_vault describes enum values but doesn't explain the semantic difference (filename=exact match vs content=substring search?). Overall, definitions are functional but lack the rigor expected of production tools.
Create a new markdown file in the Obsidian vault. Creates intermediate directories if needed.
Delete a file from the Obsidian vault. The file must exist.
Read operations on the Obsidian vault: list files, read a note (with metadata and links), or search by filename/title/tags/content.
Update an existing note in the Obsidian vault. Use action=replace for full content replacement, or action=patch for targeted string replacement.
read_vault violates single-responsibility principle by combining list, read, and search into one tool with conditional parameters
Output schemas are not documented. LLMs cannot infer what fields to expect from tool responses (e.g., does read_vault return 'title' or 'name'? does it include 'internalLinks'?)
Parameter 'path' in all tools lacks constraints: no min/max length, no regex pattern, no guidance on legal characters. LLMs may pass invalid paths like '../etc/passwd'
delete_note is destructive but lacks confirmation/dry-run safety mechanism. No error handling guidance for user on how to recover from accidental deletion
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 8 | - | v1 |
update_note combines 'replace' and 'patch' actions with conditionally required parameters (content for replace, oldString+newString for patch). Dependencies are stated but could be violated by LLM. No validation error guidance
read_vault 'by' parameter enum (filename, title, tags, content) lacks semantic explanation. Does 'filename' match exactly or substring? Does 'tags' match all or any? LLMs will guess
No error handling patterns. Tools don't document expected errors (e.g., 'path not found', 'permission denied', 'invalid regex in search'). LLM has no recovery guidance