Loading ToolBench
Obsidian MCP Server - Access and manage your Obsidian vault
This Go MCP server provides 7 tools for Obsidian vault management with basic structure but significant gaps in schema completeness, parameter descriptions, and output documentation. Tool names follow verb_noun convention (get_note, create_note, etc.), which is positive. However, input schemas are inferred from Go struct tags rather than explicitly declared in the tool registration, the actual mcp.AddTool() calls in main.go show only Name and Description, with no InputSchema field visible. This means schemas are derived at runtime from jsonschema struct tags, making them harder to verify statically. Parameter descriptions exist but are minimal (10-30 chars), below the baseline of 72 chars. Output schemas are defined as Go struct types but are not explicitly documented in the tool registration or returned alongside results. Error handling returns wrapped errors rather than actionable recovery guidance. Security measures (path validation, content sanitization) are present in implementation but not declared in tool descriptions. The server uses STDIO transport, which is a hard cap at 50/100 for protocol readiness but does not directly affect definition quality scoring.
Create a new note with the specified path and content
Delete a note by its path
Get the content of a note by its path
Get information about the vault (authentication status, version, statistics)
List all notes in the vault or in a specific folder
Search for notes containing the specified query
Update an existing note with new content
Input schemas are not explicitly declared in mcp.AddTool() registrations. Schemas are inferred from Go struct tags (jsonschema directives), making them non-verifiable from the MCP server registration code. The actual InputSchema parameter is missing from all tool registrations.
Output schemas are not documented or returned as part of the tool definition. Each tool returns a specific output type (NoteContentOutput, MessageOutput, etc.), but these are not exposed in the MCP tool metadata. Clients cannot know what fields to expect.
Parameter descriptions are minimal (10-30 characters), below the 72-character baseline. Examples: 'Path to the note file' (22 chars), 'Content of the note' (20 chars). Descriptions lack context about format, constraints, or when to use the tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Error responses return wrapped errors (e.g., 'failed to get note: %v') without actionable recovery guidance. Errors do not categorize failures as retryable, user-fixable, or fatal. LLM receives no guidance on what to do next.
Destructive operation (delete_note) lacks confirmation or dry-run support. No mention in description that this action is irreversible. Tool should declare destructiveHint: true and ideally support a confirm step.
list_notes accepts optional 'folder' parameter but provides no guidance on pagination. Results are returned as a single string ('notes') with no limit or total count. Large vaults could return thousands of notes, exhausting context.
security.ValidatePath() and security.SanitizeContent() are called but not documented. Tool descriptions do not mention that paths are validated against traversal attacks or that content is sanitized. Users cannot understand security guarantees.
Output fields are generic strings ('content', 'message', 'notes', 'results', 'info') rather than structured objects. Response structs define only string fields; returning JSON-serialized strings requires LLM to parse unstructured text, wasting tokens and increasing errors.
No tool annotations present. Destructive tools (delete_note) should declare destructiveHint: true. Read-only tools (get_note, list_notes, search_notes, get_vault_info) should declare readOnlyHint: true. Idempotent tools should declare idempotentHint: true.