Loading ToolBench
MCP server for working with Obsidian vaults. Provides tools for reading, creating, editing, and analyzing notes; canvas and workflow management; semantic search; and knowledge graph operations.
The Obsidian MCP server defines 24 tools across two functional areas (generic canvas operations and workflow management). Most tools have names following verb_noun patterns and include descriptions, but significant quality gaps exist. Parameter descriptions vary widely in completeness. Output schemas are not formally documented. Error handling is present but generic. The server uses fastmcp framework which provides basic registration, but tool definitions lack the rigor expected of production systems. Strengths: clear naming convention, comprehensive canvas and workflow operations, explicit input parameter types via Pydantic. Weaknesses: output schemas undocumented, parameter descriptions sometimes vague or missing details, no explicit error guidance or recovery paths, no tool annotations (readOnlyHint, destructiveHint), no pagination guidance for list operations, no idempotency guarantees documented.
Add a text card to a canvas file. Card text is validated against vault rules; any violations are reported alongside the confirmation.
Connect two nodes with a directional arrow. Rejects if it would create a cycle.
Create a new group/area in a canvas file.
List all .canvas files in the vault or in a specific folder.
Reposition a node by setting its absolute x/y coordinates. Works for any node (card or group). Use canvas_read to inspect current positions; coordinates grow right (x) and down (y).
Read a canvas file and return a human-readable summary of its nodes, edges, and groups.
Output schemas not formally documented. Tools return `.to_display()` summaries but LLM-facing schema for response structure is absent. Agents cannot reliably parse results or chain operations.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares Risk levels (READ_ONLY, WRITE, DESTRUCTIVE) in metadata but does not translate these to MCP tool annotations that agents can respect.
Parameter descriptions lack validation constraints. E.g., canvas.add_card 'color' accepts "0"-"6" but description does not formally specify enum constraint or min/max. LLM may pass invalid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Delete a card and all its connected edges from a canvas.
Delete a connection between two nodes.
Delete a group/area from a canvas. By default only the group container is removed; the cards it visually contained stay on the canvas. Set remove_contents=True to also delete every card inside the group's bounding box.
Update the text and/or color of an existing card. New text is validated against vault rules; any violations are reported alongside the confirmation.
Add a dependency: from_task blocks to_task. Rejects cycles.
Approve a proposed task: purple (Proposed) → red (To Do). RELAXED mode only.
List tasks that are blocked and what is blocking them.
Mark a task as done: cyan (Review) → green (Done). RELAXED mode only.
Update a task's description body. Task must be orange (or cyan in RELAXED mode).
Finish a task: orange (Doing) → cyan (Review).
Initialize a new project canvas with groups, legend, and optional tasks.
Pause a task: orange (Doing) → red (To Do).
Add a new group/phase to the project canvas.
Propose a new task (creates purple card). Auto-assigns the next task ID.
List tasks that are ready to start (red/To Do with all dependencies met).
Start a task: red (To Do) → orange (Doing). Validates dependencies are met.
Get a board overview: task counts by state, groups, total tasks.
Show details for a specific task: state, group, description, dependencies.
Error handling is generic ('Error reading canvas: {e}'). Does not classify errors as retryable vs user-fixable nor provide recovery guidance. LLM cannot determine next action.
List operations (canvas.list, kanvas.ready, kanvas.blocked) lack pagination parameters (limit, offset, next_cursor). Large vaults could return unbounded result sets, exhausting context window.
Kanvas workflow tools use idiomatic task IDs (e.g., 'DEV-01') but no parameter description specifies the format or provides examples of valid IDs. LLM may construct invalid IDs.
Destructive operations (canvas.remove_card, canvas.remove_group, canvas.remove_edge) require 'confirm' boolean parameter. No confirmation request pattern (MRTR / result input_required) documented. Agents may bypass confirmation.
Tool names 'kanvas.start', 'kanvas.finish', 'kanvas.pause' are vague about state transitions. Description clarifies (e.g., 'red → orange') but names alone do not convey the transformation. Better: 'kanvas.mark_doing', 'kanvas.mark_reviewing', 'kanvas.mark_todo'.