Loading ToolBench
Obsidian Knowledge-Management MCP (Model Context Protocol) server that enables AI agents and development tools to interact with an Obsidian vault. It provides a comprehensive suite of tools for reading, writing, searching, and managing notes, tags, and frontmatter, acting as a bridge to the Obsidian Local REST API plugin.
The server provides 18 tools with consistent registration patterns and basic schemas. However, most tool descriptions are minimal (15-35 characters), well below the 194-character baseline for production tools. Parameter descriptions exist but are generic. Output schemas are not documented. Most tools lack error handling guidance. The naming convention is solid (verb_noun pattern), but parameter descriptions fail to explain constraints, expected formats, or valid ranges. Overall, this is a fair-to-poor implementation that requires significant documentation and error handling work before production deployment.
Work with block references and headings in Obsidian files
Create a new task in the Obsidian vault
Execute Dataview queries on the Obsidian vault
Delete a file from the Obsidian vault
Search across all files in the Obsidian vault using global search
Analyze note connections and relationships in the Obsidian vault graph
List all files in the Obsidian vault
Tool descriptions are critically short (15-40 chars). Baseline is 194 chars. Descriptions like 'Read the contents of a file from the Obsidian vault' (52 chars) and 'Manage YAML frontmatter in Obsidian files' (41 chars) lack guidance on WHEN to use the tool, what it returns, and dependencies. LLMs cannot reliably select tools based on such minimal context.
Output schemas are not documented in any tool. The rubric baseline requires 100% of A+ tools to have documented return types. Clients cannot plan downstream tool calls or extract relevant fields without knowing what fields each tool returns. For example, obsidian_read_file does not document whether it returns raw content, a structured object with metadata, or an error object.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Manage YAML frontmatter in Obsidian files
Manage tags in Obsidian files
Manage periodic notes (daily, weekly, monthly, etc.) in Obsidian
Read the contents of a file from the Obsidian vault
Search and replace content in files across the Obsidian vault
Create and manage smart links between notes in Obsidian
Query tasks in the Obsidian vault
Build and execute complex task queries using the Tasks plugin
Work with Obsidian templates for creating notes from templates
Update the contents of a file in the Obsidian vault
Update an existing task in the Obsidian vault
Parameter descriptions are generic and lack constraints. For example, 'contextLength' in obsidian_global_search is described as 'Number of characters of context around matches' but does not specify the valid range (e.g., 10 - 1000 chars), default value, or what happens if omitted. Similarly, 'operation' enums in obsidian_manage_frontmatter and obsidian_manage_tags lack individual descriptions explaining what each enum value does.
No error handling guidance in any tool. Destructive tools (obsidian_delete_file, obsidian_search_replace, obsidian_update_task) do not document recovery actions, confirmation requirements, or reversibility. The rubric requires error responses to tell the LLM what to do next and classify errors as retryable, user-fixable, or fatal. No tool implements dry-run or confirmation patterns for irreversible operations.
No pagination support declared. obsidian_list_files and obsidian_graph_analysis (get_vault_stats, find_hub_notes) may return large result sets, but no limit, offset, or page_size parameters are visible. The rubric baseline requires pagination with total count or next_cursor to prevent context window exhaustion. Without caps, an agent could receive thousands of items, wasting tokens and inviting hallucination.
Tool composition gaps. Multiple read-heavy operations (obsidian_dataview_query, obsidian_task_query, obsidian_tasks_query_builder) exist with overlapping intent. LLMs will waste reasoning cycles deciding between them. Additionally, if obsidian_create_task, obsidian_update_task, and obsidian_periodic_notes all modify state but do not return the modified object, agents cannot chain operations without separate read calls (violating idempotency and chaining patterns).
Parameter naming inconsistency. Some tools use 'filePath' (obsidian_read_file, obsidian_delete_file), while others may use 'file' or 'path'. If tools expect consistent field names for chaining (e.g., obsidian_list_files returns 'filePath' but obsidian_read_file requires 'filePath'), it works, but if naming differs, agents face manual field mapping, increasing errors.
No idempotency declarations. Tools like obsidian_update_file and obsidian_search_replace modify state but do not declare whether repeated calls with the same inputs produce the same result. Agents may retry on ambiguous failures, risking duplicate side effects (e.g., appending the same content multiple times or duplicating replacements).