Loading ToolBench
27 tools with complete schemas and descriptions. Naming is verb-noun consistent (obsidian_*). Descriptions are present but often generic (10-50 chars), lacking LLM-optimized context about WHEN to use each tool or what distinguishes similar operations. Parameters are typed (string, boolean, integer, array, object) but many lack actionable constraints (enums, ranges, patterns). Output schemas are not documented, LLMs cannot predict response structure. Error handling is basic (errorResult wrapper) with no recovery guidance. Security: vault parameter is optional with implicit default, risking silent cross-vault operations. Composition is good, tools are single-responsibility and chainable via file/path parameters.
Add a tag to a note
Append content to an existing note
Create a new note with optional topic routing
Delete a note (requires confirmation)
Disable a plugin
Enable a plugin (requires confirmation)
Execute arbitrary JavaScript in the Obsidian context (requires confirmation)
Get the currently active note in Obsidian
Output schemas not documented. LLMs cannot predict response structure (fields, types, nesting). Responses are wrapped in {content, structuredContent?, isError?} but the actual data shape is opaque.
Descriptions are too generic and lack LLM-optimized context. Most are 10-60 chars (below 194-char baseline). Missing WHEN to use, what distinguishes from similar tools, and what to expect in response. E.g., 'Get metadata for a note' doesn't explain what metadata includes or when to call it vs read_note.
Optional vault parameter with implicit default creates silent cross-vault risk. If vault is omitted, operations target 'most recently focused vault', an LLM cannot predict which vault will be affected. Should either require vault or document the default prominently and validate it matches user intent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2025-06-18+ | v2 |
Get or create today's daily note
Get metadata for a note (frontmatter, links, tags, etc.)
Get information about open editor panes
List all files in the vault root (not in subfolders)
Move a note to a different folder
Apply an organization plan (move notes to folders)
Scan vault root and suggest folder organization based on topics
Validate an organization plan before applying
Read the full content of a note
Remove a property from a note (requires confirmation)
Remove a tag from a note
Rename a note
Rename a tag across all notes (requires confirmation)
Scan vault root files with optional filtering and frontmatter extraction
Search for notes by keyword or regex
Set metadata (frontmatter) on a note
Set a property on a note
Remove a topic from the stored routing map
Get statistics on stored topic→folder mappings
Destructive/irreversible tools (delete_note, eval, enable_plugin, organize_apply) lack dry-run or explicit confirmation guidance. confirm parameter exists but description doesn't explain what happens if false or how elicitation works. No recovery guidance if operation fails.
Parameters lack actionable constraints. 'query' in obsidian_search has no format/pattern guidance (keyword vs regex?). 'metadata' in set_metadata is type:object with no schema. 'plan' in organize_apply is array with no item schema. LLMs cannot validate inputs without explicit constraints.