Loading ToolBench
MCP server for Obsidian diary with smart templates and auto-tagging
This server exhibits significant definitional gaps that prevent confident LLM use. While tool names follow verb-noun conventions (create_diary_entry_file, read_diary_entry, etc.), several critical issues undermine quality. Parameter descriptions are present but generic, many lack explicit format constraints, value ranges, or usage context beyond the date parameter. Output schemas are entirely undocumented; the server returns string responses without structured fields, forcing LLMs to parse freetext and losing composability. Error handling is minimal: tools return string error messages but do not guide recovery (e.g., 'Error creating file: Permission denied or I/O error' gives no actionable next steps). Tool descriptions vary widely in quality, some are verbose and narrative ('Create a sophisticated diary template...') rather than actionable; others are missing concrete guidance on when to use them relative to similar tools. Tool annotations are present (readOnlyHint, destructiveHint, idempotentHint), a positive sign, but do not compensate for missing schemas and weak error handling.
Complete your diary entry - automatically generates Obsidian-compatible memory links and provides cognitive analysis. Use this when you're done writing. Creates [[YYYY-MM-DD]] backlinks that integrate with Obsidian's backlink system.
CREATE A NEW DIARY LOG ENTRY for a specific date with AI-generated analytical prompts for deep intellectual exploration. Use this tool when you want to start a new diary entry for today or any specific date.
Create a sophisticated diary template with intellectually rigorous prompts for deep cognitive exploration.
List recent diary entries (inferred from source code pattern, actual docstring truncated)
Read a specific diary entry by date.
Update backlinks for recent diary entries only - much faster than full refresh.
No output schemas documented for any tool. All tools return unstructured strings. LLMs cannot parse results reliably or compose downstream calls.
Semantic overlap between create_diary_template and create_diary_entry_file. Both accept date and focus parameters and generate prompts. Descriptions do not clarify WHEN to use each.
Unclear distinction between complete_diary_entry, update_entry_backlinks, and refresh_recent_backlinks. All three appear to update backlinks. Descriptions do not explain operational differences or when to choose each.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Update the backlinks for an existing diary entry based on its current content.
Error messages are generic and do not guide recovery. E.g. 'Error creating file: Permission denied or I/O error' does not tell the LLM what to try next. No error classification (retryable vs user-fixable).
Tool descriptions are narrative and marketing-oriented ('intellectually rigorous prompts', 'cognitive analysis') rather than functional. Lack actionable context for LLM decision-making.
Parameter 'focus' in create_diary_template and create_diary_entry_file is marked optional but has no format constraints or examples. What constitutes a valid focus area? Are there enums?
read_diary_entry returns an entire file as a string with no size limits or pagination. Large entries could blow token budgets. No documented max size or chunking strategy.
Tool annotations present (readOnlyHint, destructiveHint) but inconsistent. create_diary_entry_file is marked destructiveHint=false despite being a WRITE operation. idempotentHint=true may be incorrect if re-calling creates duplicate content.