Loading ToolBench
This MCP server defines 10 tools for Obsidian note management. Tool definitions are inferred from TypeScript interface declarations in obsidian-cli.d.ts rather than from explicit MCP server registration code. No Java implementation files are visible in the provided source, making it impossible to verify actual schema enforcement, error handling, or response documentation. All tool names follow verb_noun convention (obsidian_<action>), which is good. However, parameter descriptions are minimal (5-20 words), output schemas are entirely undocumented, and there is no evidence of error handling, validation, or recovery guidance. The definitions appear to be transcribed from CLI help text rather than designed for LLM interaction. Per-tool scores average to 42, placing this in the D (Poor) range.
Get backlinks for a file in Obsidian
Create a new note in Obsidian
List properties in Obsidian vault
Set a property value on a file in Obsidian
Search for content in Obsidian vault with query operators (path:, file:, tag:, line:, section:)
List tags in Obsidian vault
Get or modify a specific task in Obsidian. ref is shorthand for file+line, e.g. ref="folder/note.md:12"
List tasks in Obsidian vault
Tool definitions are inferred from TypeScript type declarations, not from explicit MCP server implementation code. No Java source files showing actual tool registration, schema validation, or response handling are provided.
No output/response schemas are documented for any tool. LLMs cannot plan downstream calls or extract structured data if they do not know what fields a tool returns. E.g., obsidian_search does not specify whether it returns [{file, line, excerpt}] or {results: [], total: 0} or plaintext.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Find unresolved references in the entire vault
Get information about the Obsidian vault
Parameter descriptions are minimal and generic. Most describe WHAT a parameter is (e.g., 'Path where the note should be created') but not HOW to use it or what format to expect. None mention constraints, valid ranges, or LLM guidance.
obsidian_search lists query operators (path:, file:, tag:, line:, section:) in the tool description but does NOT document output structure. Without knowing whether results are JSON or plaintext, an LLM cannot reliably extract file paths or line numbers to pass to obsidian_task.
obsidian_task accepts both 'ref' (shorthand 'file/path:line') and separate 'file', 'path', 'line' parameters. No description clarifies whether these are mutually exclusive, what happens if both are provided, or which takes precedence. This violates the parameter-relationships pattern.
obsidian_tasks and obsidian_task accept 'format' enums (json, tsv, csv, text) but do NOT document what structure each format returns. An LLM calling obsidian_tasks(format='json') cannot parse the result if the JSON schema is not specified.
No error handling or recovery guidance documented. If obsidian_create fails (file already exists, invalid path, permission denied), the tool description does not explain what the LLM should try next. Per pattern:recovery-guide, errors must tell the agent what to do.
obsidian_create and obsidian_task are destructive (write/modify), but descriptions do NOT indicate this. Per pattern:command-tool, write tools must explicitly state 'This creates/modifies/deletes' so LLMs know which calls have irreversible consequences.
No input validation rules documented. obsidian_search accepts a 'limit' parameter but does not specify min/max (is limit=999999 allowed?). obsidian_property_set accepts 'type' enum but does not explain what 'date' vs 'datetime' means or expected format.
obsidian_properties and obsidian_tags accept both 'file' and 'path' parameters. No description clarifies whether 'file' is a filename only and 'path' is a full path, or if they are aliases. This creates ambiguity for LLMs.