Loading ToolBench
MCP server for Obsidian vault operations
The server provides 8 tools with explicit schemas and basic descriptions. However, descriptions are consistently too short (averaging ~35 chars, well below the 194-char baseline), and parameter descriptions lack depth. Tool names follow verb_noun convention well (e.g., read_file, create_file, list_files). Schemas are present and properly typed with JsonSchema derivation visible in the code (serde, schemars dependencies). The critical issue is insufficient guidance in descriptions for LLM tool selection and parameter usage, descriptions state WHAT the tool does but rarely explain WHEN to use it or HOW parameters interact. Error handling and recovery guidance are absent from responses. No output schema documentation is evident in parameter descriptions. Overall, this is a functional but mediocre definition set typical of community servers.
Create a new file in the vault
Get or create today's daily note (returns {content, path})
List files in vault directory
Replace a substring within a file
Read file from vault
Search for files by name pattern in vault
Move file to trash (delete)
Update entire file content
All tool descriptions are under 50 characters, well below the 194-char baseline. They state only WHAT the tool does (get/read/create) but not WHEN to use it or how it differs from similar tools. LLMs cannot distinguish list_files from search_files without longer, comparative descriptions.
Parameter descriptions are missing or minimal. 'path' parameter appears in 6 tools with only 'Relative path to file' or 'Directory path', no guidance on format, constraints, or examples. No mention of path traversal safety, allowed characters, or length limits. Violates pattern:tool-description requirement for non-empty parameter descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No output schemas documented in descriptions or parameter definitions. Responses return structured objects (ReadFileResult, DailyNoteResponse, MessageResponse) but LLM has no visibility into what fields to expect. Pattern:tool-description and pattern:response-shaper require documented output types so LLMs can plan downstream calls.
Destructive operations (trash_file) and write operations (create_file, update_file, patch_file) lack confirmation or dry-run guidance. No mention in descriptions that these are irreversible or stateful. Pattern:confirmation-request and pattern:command-tool require state-modification tools to clearly indicate side effects.
No error handling or recovery guidance documented. No descriptions mention what happens on path traversal attempts, file not found, permission errors, or vault path misconfiguration. Pattern:recovery-guide requires error responses to tell the LLM what to do next.
patch_file tool accepts 'old_string' and 'new_string' parameters but no description warns about substring matching semantics (e.g., case sensitivity, multiple matches, partial matches). LLM cannot infer behavior or error cases. Parameter descriptions must state format and constraints per pattern:constrained-input.
search_files accepts 'query' parameter with no constraints. No description states whether it's regex, glob, substring, or exact match. No mention of character limits, special character handling, or case sensitivity. Pattern:constrained-input requires enums or format constraints for free-form inputs.
daily_note tool relies on template configuration (DailyNoteCfg) but the description does not mention it depends on YAML config or explain what happens if no config is provided. Pattern:tool-description requires dependencies and prerequisites to be explicit.