Loading ToolBench
Model Context Protocol server for Obsidian Vaults
The server provides 9 read-only tools for Obsidian vault interaction with basic input schemas and descriptions. However, there are significant gaps in schema completeness, parameter documentation, and output structure definition. Most tools have descriptions in the 50 - 150 character range, which is adequate but minimal. Parameter descriptions are present but often generic. Output schemas are not documented anywhere in the provided code, and error handling lacks recovery guidance. The tools are well-named with clear action verbs (read_, search_, list_, get_, find_) and are appropriately scoped for single responsibilities. Security is reasonable (read-only operations, path validation), but definition quality falls short of production baselines due to missing output documentation and incomplete parameter constraints.
Find all notes that link to a specific target note (backlink graph).
Count the number of markdown files in the vault or a specific folder.
Extract and return the YAML frontmatter from a specific note.
Get a comprehensive list of all tags found in the vault (from frontmatter and inline markdown tags).
Find notes by one or more tags. Can match any or all of the specified tags.
Execute an Obsidian dataview query (supports both dataview query language and inline queries).
Read the contents of one or more notes. Returns the file path, frontmatter, and body content of each note.
Search note content for a specific query string. Supports regex patterns and returns matching lines with optional context.
No output schemas documented for any tool. LLMs cannot determine what fields are returned, making downstream tool chaining impossible and forcing agents to guess at response structure.
search_notes and search_content accept free-form query strings with optional regex support but do not specify regex syntax, flags, or example patterns. Unclear whether both regex and fuzzy matching work simultaneously or are alternatives.
obsidian_query tool name is non-standard (obsidian_ prefix is framework-specific jargon, not an action verb). Should be execute_dataview_query or similar. Additionally, 'dataview query language and inline queries' in description is vague, no examples or syntax guidance provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 21 | - | v1 |
Search for notes in the vault by filename or fuzzy match. Supports wildcards (*) for pattern matching.
search_notes, list_tags, and search_content have optional maxResults parameters but no documentation of default values, hard limits, or rationale. Baseline establishes limits should be explicit (e.g., 'default 20, max 200').
Parameter descriptions are present but minimal (10 - 40 chars in many cases). 'Array of relative file paths to read' is adequate, but descriptions like 'Search query for note filenames' lack context on syntax, wildcards, or behavior when query matches nothing.
No error recovery guidance. Descriptions do not explain what happens if a path is invalid, a note does not exist, or a dataview query fails. LLMs receive raw errors with no hint on next steps.
read_notes headersOnly parameter description is clear, but there's no guidance on the exact format of header-only output (does it preserve indentation? return just the text? include line numbers?).
notes_by_tag match parameter is an enum ['any', 'all'] but description does not clarify the default or what happens if not specified. Code suggests it's optional, but LLM behavior when defaulting is unpredictable.
search_content maxResults and obsidian_query maxResults parameters accept positive integers with no min/max bounds documented. Code defines CONTENT_SEARCH_LIMIT=200 and SEARCH_LIMIT=200 but these limits are not surfaced in parameter descriptions.