Loading ToolBench
Comprehensive, model-agnostic, agent-ready Obsidian MCP server with 148+ tools for knowledge management, semantic search, and note manipulation
obsidian-tc demonstrates above-average definition quality with well-structured tool schemas, clear verb-led naming conventions, and detailed parameter descriptions. All 9 tools have explicit input schemas with types and descriptions. Descriptions average ~120 chars, within the 10-1024 ideal range. However, there are notable gaps: (1) output schemas are entirely undocumented, no response structure is defined for any tool, preventing LLMs from planning downstream operations; (2) error handling lacks recovery guidance, tools specify what can fail but not what the LLM should do next; (3) tool composition has redundancy with backwards-compatibility aliases (health/index_status duplicate server_health/get_index_status); (4) parameter constraints are loose in places (no enforced ranges for numeric params like max_notes, limit); (5) no tool annotations present (readOnlyHint, destructiveHint, idempotentHint), forcing LLMs to infer from descriptions alone. The frontmatter tools are well-designed (read_frontmatter, read_property, update_frontmatter, list_properties, find_notes_by_property) with clear domain focus and progressive complexity. The update_frontmatter tool properly gates destructive operations via requireConfirmation and prev_hash (CAS), following pattern:confirmation-request. Overall, strong parameter and naming hygiene, but incomplete schemas and missing error recovery guidance limit LLM reasoning effectiveness.
Find notes matching a property key/value, with optional membership (e.g. tag matches arrays). Returns up to limit matches; set verbosity=terse to drop the matched value.
Retrieve index status: reconciliation state, write failures, notes ready, chunks upserted, and in-flight progress.
Alias for server_health for backwards compatibility.
Alias for get_index_status for backwards compatibility.
Enumerate all frontmatter properties across notes in a vault or folder, with key frequencies and type distribution.
Read a note's parsed YAML frontmatter (null when the note has none). Domain: metadata.
Output schemas completely undocumented for all tools. LLMs cannot plan downstream operations, extract chaining IDs, or reason about response structure.
Error handling lacks recovery guidance. Tools describe what can fail but not what the LLM should do next (retryable? user-fixable? fatal?).
Backwards-compatibility aliases (health, index_status) have generic names and minimal descriptions. They add cognitive load to LLMs and should be removed or clearly marked as deprecated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2025-06-18+ | v2 |
Read a single frontmatter property. Set nested=true to address a dotted path (e.g. meta.author.name) through nested objects.
Report server health: build capabilities (native module, sqlite-vec, FTS), vault count, startup time, index status, and optional authenticated details (index queue depth, write failures, last error).
Update a note's frontmatter with set, remove, merge, or replace operations. Gates on confirmation via requireConfirmation for replace operations.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs must infer intent from descriptions alone, risking misclassification.
Numeric parameter constraints are loose. list_properties max_notes (default 5000) has no documented min/max; find_notes_by_property limit has no stated bounds. LLMs could pass absurd values.
update_frontmatter parameter dependencies are undocumented. key/value/properties optional status depends on operation type, but this is not formally stated or cross-referenced.
HITL confirmation flow (elicit_token parameter) is mentioned but unexplained. No guidance on token format, generation, or how confirmation actually works.