Loading ToolBench
MCP server for any Markdown vault as a second brain (Obsidian, Foam, Logseq, plain files)
This MCP server provides 8 well-defined read-only tools for querying a Markdown vault. Tool names follow verb_noun conventions (search_notes, get_note, list_tags), which is good for LLM parsing. Descriptions are present for all tools and range from 72-186 characters, meeting the 10-1024 character baseline. Input schemas are fully specified with proper JSON Schema types and descriptions for all parameters. However, there are critical gaps: (1) Output schemas are undocumented, the code shows tools return structured responses (NoteSummary objects, note lists) but the Tool definitions lack outputSchema declarations, forcing LLMs to infer result structure. (2) Several parameter descriptions lack actionable constraints, e.g., 'path' in get_note has no guidance on format or path separator conventions. (3) Error handling is basic, error responses are created via createErrorResponse() but the tool definitions provide no guidance on recovery steps. (4) No tool annotations (readOnlyHint, etc.) despite all 8 tools being read-only, these should be declared explicitly. (5) Default values are present (limit=20, daysSinceModified=14) but lack justification in descriptions. The tools are functionally sound for a knowledge-base use case, but LLM integration would be stronger with output schema documentation and error recovery guidance.
Scan the vault for structural gaps: wikilinks pointing to non-existent notes and notes containing unanswered questions
Retrieve the full content of a specific note by its path
Get all notes with a specific tag
Return notes not modified in N days, sorted by importance (inbound link count). Useful for spaced-repetition review.
Get the most recently modified notes
List all unique tags used across all notes
Search notes in the Obsidian vault using semantic search with optional filters
Output schemas are not documented in Tool definitions. The code implements structured responses (NoteSummary, arrays of notes) but Tool objects lack outputSchema declarations. LLMs cannot predict result structure without this.
Missing tool annotations. All 8 tools are read-only operations, but no readOnlyHint annotations are present. This prevents MCP clients from understanding operation safety and idempotency.
Parameter descriptions lack actionable constraints. Examples: 'path' in get_note has no guidance on format (expected separator, file extension handling). 'query' in search_notes does not clarify if empty string lists all notes or is an error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get a summary of notes matching criteria
Error handling lacks recovery guidance. The server generates error responses via createErrorResponse(), but Tool descriptions do not document what errors are possible or how LLMs should recover (e.g., 'If note not found, try search_notes() to verify the path').
Default values lack justification. Parameters like limit=20, daysSinceModified=14, and limitOrphanLinks=50 have defaults, but descriptions do not explain why these specific numbers were chosen. This makes it unclear if an LLM should override them.