Loading ToolBench
MCP server to work with Obsidian via the remote REST plugin
Server defines 16 Obsidian tools with mixed quality. Most tool names follow verb_noun conventions (list_files_in_dir, simple_search, patch_file, put_file, append_to_file, delete_file). However, critical gaps exist: 10 of 16 tools lack visible input schemas or descriptions in the provided source code (obsidian_delete_file, obsidian_complex_search, obsidian_batch_get_files, obsidian_get_active_note, obsidian_periodic_notes, obsidian_recent_periodic_notes, obsidian_recent_changes, obsidian_understand_vault, obsidian_open_files, obsidian_list_commands, obsidian_execute_commands). Tools with visible definitions (list_files_in_dir, simple_search, patch_file, put_file, append_to_file) have adequate naming and reasonable schemas, but descriptions are brief (50-150 chars) and lack guidance on when to use them vs alternatives. No output schemas are documented. Error handling is basic (RuntimeError for missing params) with no recovery guidance. Missing tool definitions are inferred from constant declarations only, capped at 50 per HARD SCORING RULE #3.
Append content to a new or existing file in the vault.
10 of 16 tools (62.5%) lack visible input schemas and descriptions in source code. Only tool constants are declared; implementation is not shown. Per HARD SCORING RULE #3, tools without visible definitions cap at 50.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract specific fields from responses. Violates pattern:tool and pattern:response-shaper.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 14 | - | v1 |
Lists all files and directories that exist in a specific Obsidian directory.
Insert content into an existing note relative to a heading, block reference, or frontmatter field.
Create a new file in your vault or update the content of an existing one in your vault.
Simple search for documents matching a specified text query across all files in the vault. Use this tool when you want to do a simple text search
Tool descriptions are brief (50-150 chars) and lack context on WHEN to use each tool vs alternatives. E.g., simple_search vs complex_search distinction is never explained. Descriptions should be 150-300 chars with actionable guidance.
Error handling is minimal. Only RuntimeError('argument missing') is visible. No error recovery guidance, no suggestion of alternative tools or fallback actions. Violates pattern:recovery-guide.
Destructive tool (obsidian_delete_file) has no visible confirmation or dry-run mechanism. Agents can delete files without safeguard. Violates pattern:confirmation-request.
No pagination support visible for listing/search tools. obsidian_list_files_in_dir and obsidian_simple_search do not declare limit or offset params. Large vaults could return unbounded results.
Parameter 'target_type' in obsidian_patch_file accepts enum values (heading, block, frontmatter) but no guidance on how to specify block references or frontmatter field names. Likely to cause LLM errors.
Obsidian API key and host are injected as environment variables (OBSIDIAN_API_KEY, OBSIDIAN_HOST) but no documentation on how to securely configure them. Vault path default is empty string, risking misconfiguration.