Loading ToolBench
Personal MCP tool for managing Obsidian vault notes and project workflows with git integration
Server has 8 tools with clear verb-noun naming (get_, list_, update_, patch_, search_, commit, init). All tools have descriptions (10 - 200 chars, within baseline). Input schemas use Zod with type definitions and descriptions. However, output schemas are undocumented, responses are wrapped in a generic `out()` helper that returns text or JSON without declaring structure. Error handling is minimal: API failures throw raw error messages without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Parameter descriptions are adequate but lack format constraints (e.g., path format, heading nesting rules). Missing idempotency guarantees for write operations.
Commit the already-staged files in the project repo with your own git identity. Does NOT stage and does NOT push.
Read the note currently open in Obsidian.
Read a note from the vault by its vault-relative path (e.g. 'Dev days/foo.md').
Read your roles note (Templates/Claude/Implementing Role.md) and write it into the project's CLAUDE.md, inside a managed block.
List files/folders in the vault, or inside a given folder (e.g. 'Dev days/').
Insert content relative to an existing heading in a note (PATCH).
Output schemas undocumented. All tools return generic `{content: [{type: 'text', text: string}]}` via `out()` helper. LLMs cannot infer what fields to extract or how to chain results. Violates pattern:tool requirement for documented return types.
No tool annotations despite clear risk levels. `update_note`, `patch_note`, `commit`, `init` are destructive but lack destructiveHint. `get_note`, `get_active`, `list_notes`, `search` are read-only but lack readOnlyHint. Agents cannot distinguish safe from risky operations.
Error handling lacks recovery guidance. API failures throw raw messages like '${method} ${path} -> ${res.status} ${text}'. No categorization (retryable vs fatal), no suggestions for next steps. Violates pattern:recovery-guide.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Plain-text search across the vault.
Create or overwrite a note at the given path with the given markdown (PUT).
`patch_note` heading parameter lacks format documentation. Description says 'nest with ::' but does not specify: are spaces trimmed? Is case-sensitive matching required? What happens if heading not found? Ambiguity invites LLM errors.
Write operations (`update_note`, `patch_note`, `commit`, `init`) lack idempotency guarantees. No documentation of retry behavior or duplicate-prevention. Agents may accidentally create duplicate commits or overwrite notes on retry.