Loading ToolBench
MCP server for interacting with Obsidian vaults via TypeScript. Provides tools for note creation, reading, searching, and metadata management. Marked as deprecated in favor of DevJournal.
The server defines 32 tools with generally clear naming and descriptions, but exhibits significant inconsistencies in schema completeness and parameter documentation. Most tools have descriptive text (averaging ~150 chars), but many parameters lack type declarations in the visible schema fragments. Parameter descriptions are present but often terse. Output schemas are not documented, no tool specifies what fields it returns or the structure of results. Error handling is not evident in the tool definitions. The codebase is well-organized and the server is marked deprecated (superseded by DevJournal), which raises questions about maintenance. Conservative scoring reflects missing output schema documentation and inconsistent parameter type visibility across the 32 tools.
Add an item to a project's backlog.
Append content to the end of an existing note. Useful for adding session logs, tasks, or follow-up notes to an existing document.
Create a new note in the Obsidian vault. Supports optional content and templates. Use this when you need to record a new session, decision, or piece of documentation. When 'path' is provided (or the name contains directory separators), the note is written directly to that location including any intermediate folders.
Append content to today's daily note. Creates the daily note if it doesn't exist. Useful for logging tasks, session summaries, or quick entries.
Get today's daily note path, creating it if it doesn't exist. Returns the file path of the daily note.
Read the full contents of today's daily note.
No output schemas documented. Tools do not declare what fields they return, their types, or structure. LLMs cannot infer downstream chaining requirements or extract the right data for follow-up calls. This violates the response-shaper pattern and forces agents to guess at result structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Prepend content to today's daily note, after its frontmatter.
List all notes that link to a given note (backlinks/incoming links). Provide at least one of 'file' or 'path' to identify the note.
List all wiki-style links in a note (outgoing links).
Get the heading structure/outline of a note.
Get the backlog items for a specific project.
Get a summary of a project's status and progress.
Get a frontmatter property from a note.
List all notes with a specific tag.
List all tags in the vault with their occurrence counts. Always returns all tags with counts included.
Get information about the Obsidian vault: name, path, file count, folder count, and size.
List all databases (structured views) in the vault.
List files in the vault. Can filter by folder and/or file extension.
List all projects in the vault.
List all tasks in a note. A task is a markdown checkbox line (- [ ] or - [x]).
List all template files in the vault's templates folder.
Move or rename a file in the vault.
Prepend content after the frontmatter of a note. Useful for adding a summary or status update at the top of an existing document.
Query a database view and return records.
Read the full contents of a note. Returns the markdown content including frontmatter. Provide at least one of 'file' or 'path' to identify the note.
Read the contents of a template file.
Remove a frontmatter property from a note.
Search the vault for text. Returns matching files and context. Use Obsidian's full search syntax (supports operators, tags, paths).
Set a frontmatter property on a note. Supports text, list, number, checkbox, date, datetime types.
Replace an exact string in a note with a new string. The old string must appear exactly once in the note. Use this for precise, targeted edits to note content.
Toggle the completion status of a backlog item.
Toggle the checkbox state of a task in a note (check or uncheck).
Parameter descriptions lack explicit constraints and format specifications. Many parameters (e.g., 'limit' in list_files, 'filter' in query_database) do not specify min/max bounds, valid ranges, or expected format. LLMs frequently pass invalid values like negative page counts or unbounded result sizes without explicit constraints.
No error handling guidance in tool definitions. There are no examples of what errors each tool might return, how to interpret them, or what the LLM should do next (retry, user-fixable, fatal). Error responses are not documented, violating the recovery-guide pattern.
No idempotency or confirmation hints for destructive operations. Tools like 'move_file' (REVERSIBLE) and 'str_replace_in_note' (WRITE) do not document whether they are safe to retry or if they require confirmation. Agents may accidentally execute destructive operations multiple times.
Tools with flexible identifier inputs (file vs. path in read_note, get_backlinks, etc.) do not explain resolution logic clearly. Parameter descriptions say 'Note name (resolved like internal links)' but do not specify: case sensitivity, priority if both 'file' and 'path' are provided, or what happens if neither is supplied. This creates ambiguity for LLMs.
Minimal parameter descriptions on tools with empty input schemas. 'daily_note' has no input parameters and a vague description 'Get today's daily note path, creating it if it doesn't exist.' Does it create the file immediately? Is there a configurable date format? What if the daily note already exists?
No pagination or result limits documented for list/search tools. 'search_vault' accepts a 'limit' parameter (good), but 'list_files', 'get_tags', 'get_backlinks', 'list_tasks' do not. Large vaults could return thousands of results, exhausting the context window. The rubric requires list tools to document defaults and limits.
Deprecated project management (tools 28-32: list_projects, get_project_backlog, add_backlog_item, etc.) are Obsidian-specific extensions that many vaults may not use. No documentation on whether these are optional or required, or how they gracefully fail if the vault has no projects configured. This creates agent confusion on a large installation base.