Loading ToolBench
MCP Server integration for Obsidian (https://obsidian.md)
The server defines 7 tools with basic schemas and descriptions, but suffers from significant quality gaps. All tools have descriptions present (positive), and input parameters have type definitions visible in the code. Parameter descriptions are minimal, 'file path from root' is underspecified. The 'replace_in_file' tool has an unusually long description with examples, which is an anti-pattern. No pagination support on list_files despite being a core discovery tool. The server accepts file paths as strings without validation against path traversal attacks, a critical security gap for a file manipulation tool.
Append text to a markdown file. Before using this tool, read the file using the read_file tool to check the content of the file.
Delete a markdown file
Find files that contain a specific string
List files in a directory
Read a markdown file
Replace the text that exactly matches old_text with new_text. old_text and new_text must contain at least one complete line of content. Before using this tool, read the file using the read_file tool to check the content of the file. ## arguements: - filename: file path from root - old_text: String to be replaced - new_text: String to replace with ## example: original text: ```markdown Dialy 1 Today is 2023-10-01. I was happy to meet my friend. Daily 2 Today is 2023-10-02. I was running in the park. ``` old_text="Dialy 1\nToday is 2023-10-01. I was happy to meet my friend." new_text="Dialy 1\nToday is 2023-10-01. I was happy to meet my friend and I checked my email." result: ```markdown Dialy 1 Today is 2023-10-01. I was happy to meet my friend and I checked my email. Daily 2 Today is 2023-10-02. I was running in the park. ```
Descriptions too short to guide LLM selection. 'Read a markdown file' (21 chars), 'List files in a directory' (25 chars), 'Delete a markdown file' (22 chars) all fail the 10 - 1024 character guideline and lack context about when to use each tool vs others.
No output schema documented. Tools return ToolResult(success, data, message) but the LLM cannot see what 'data' contains, whether it's a JSON string, array of file objects, raw text, or structured metadata. LLMs need documented output schemas to plan downstream calls and extract the right fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Write a markdown file. If the file already exists, it will be overwritten.
No confirmation step or dry-run for destructive operations. delete_file and write_file (overwrite) are irreversible but have no confirmation request pattern. Agents make mistakes, a 'are you sure?' step prevents catastrophic data loss.
Path traversal vulnerability. Tools accept filenames like '../../../etc/passwd' without validation. No check that the resolved path stays within the Obsidian vault root. LLM or user-controlled input could read/write arbitrary system files.
Parameter descriptions are too minimal. 'file path from root' and 'Path to directory. If None, this method returns data in the root' lack format guidance (expected file extensions?), length limits, or examples of valid input.
replace_in_file description violates anti-pattern: includes a long example with sample content. Move examples to tool invocation documentation or use enums/patterns instead. The description is 800+ chars, way above the 10 - 1024 target.
Error responses lack recovery guidance. Tools return ToolResult(success=False, data=...) but do not tell the LLM what to do next. E.g. if read_file fails, should the LLM call list_files first? Retry? Ask the user? Per pattern:recovery-guide, errors must answer 'what do I do now?'
find_files context_length parameter is poorly documented. It's optional with default 100, but what does it mean? Number of characters? Lines? Words? The context is ambiguous and invites invalid LLM usage.
No pagination on list_files. For large vaults with hundreds/thousands of files, the tool returns all items, risking context window exhaustion. Per pattern:paginated-result, discovery tools should accept limit and offset/cursor parameters and return a total count.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). These help MCP clients and agents understand tool safety at a glance. delete_file should be marked destructive; read_file should be marked readOnly.