Loading ToolBench
First HTTP-native MCP server for Obsidian - Works with Claude Code CLI, Codex, Gemini without stdio bugs
Obsidian HTTP MCP demonstrates good overall definition quality with strong naming conventions, mostly complete schemas, and clear descriptions. All 12 tools follow verb_noun naming patterns (list_dir, read_file, write_file, etc.). Tool descriptions are substantive (ranging 80-350 chars) and include important caveats (e.g., trailing slash requirements). However, several tools lack complete parameter descriptions, some descriptions contain example values contrary to best practices, and error handling guidance is minimal. Output schemas are not formally documented in source code. The server uses HTTP transport (good for protocol readiness) but lacks comprehensive error categorization.
Create a new directory. Idempotent (returns success even if already exists). Does NOT create parent directories - they must exist first.
Delete a file. By default moves to .trash-http-mcp/ for recovery. Set permanent=true for irreversible deletion.
Delete all files in a folder recursively. By default moves to .trash-http-mcp/ (soft delete). Use permanent=true for irreversible deletion. Empty folders remain (API limitation).
Surgically edit file content using exact string replacement (pattern matching). Use this for arbitrary text edits anywhere in the file. IMPORTANT: old_string must match exactly (including whitespace/indentation). Include enough context to make old_string unique. For structured edits (headings/frontmatter), consider using patch_file instead (coming soon).
Search files in vault with fuzzy matching. Use this when you don't know the exact filename.
Get file metadata (size, modification date). Returns exists: false if file not found.
Output schemas not formally documented in tool registration. While tool descriptions mention what they return (e.g., list_dir returns 'folder names'), the actual response structure, field types, and error responses are not declared in code. This forces LLMs to infer output shape from description text alone, risking misuse of return values.
Examples included in descriptions (e.g., list_dir says 'BUSINESS/' or '' for root; edit_file mentions 'Notes/meeting.md'). LLMs tend to reuse example values literally rather than adapting to context, causing incorrect file paths and API calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 12 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 66 | - | v1 |
List subdirectories in a path. Returns only folder names (not files). IMPORTANT: Path must end with / (e.g., "BUSINESS/" not "BUSINESS")
List files in a directory. Returns only files (not folders). IMPORTANT: Path must end with / (e.g., "Notes/" not "Notes")
Move or rename a file. Works for both moving to different folder and renaming in same folder.
Read content of a file. TIP: If you don't know exact filename, use find_files first. Use file path WITHOUT trailing slash (e.g., "Notes/meeting.md")
Search for text inside file contents recursively across entire vault. Use this to find files containing specific text (like grep).
Create or update a file. Use mode=create for new files, mode=overwrite to replace existing, mode=append to add to end.
Destructive tools (delete_file, delete_folder) require 'confirm' parameter but lack explicit confirmation UI or dry-run support. The description mentions soft delete via trash folder, but there is no confirm-before-execute pattern with clear feedback. An LLM might set confirm=true without fully understanding the operation's irreversibility.
Error handling and recovery guidance is minimal. Tool descriptions do not explain what errors might occur or what the LLM should do if a call fails. For example, read_file might return 'file not found' but the description offers no guidance to call find_files first.
edit_file tool requires exact string matching with old_string parameter. The description warns about whitespace sensitivity but does not explain fallback strategies if the string is not found exactly, forcing LLMs to reason about string matching on their own.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present in tool registration. Risk categories are declared in the evaluation metadata (READ_ONLY, WRITE, DESTRUCTIVE) but not in MCP tool capability annotations, limiting client-side safeguards.
Parameter 'mode' in write_file defaults to 'create' but lacks clear guidance on when to use 'overwrite' vs 'create' vs 'append'. LLMs must infer intent from context, risking accidental overwrites.