Loading ToolBench
Model Context Protocol server for LifeOS Obsidian vault management
The LifeOS MCP server provides 5 tools with generally good naming (verb-first) and detailed descriptions. However, several tools exhibit critical schema and composition issues that limit its production readiness. The search and list tools have comprehensive parameter sets with proper typing, but search_notes and create_note_from_template lack critical documentation. Tool definitions appear to be derived from test files rather than the actual server implementation (scripts/archived/ directory), which raises confidence concerns. The server consolidates multiple legacy tools into unified interfaces (search, list, create_note), which is good for composition but leaves some parameter relationships undocumented. Output schemas are described in narrative text but not formally defined in JSON Schema format.
Create a new note in the LifeOS vault with automatic template detection and proper YAML frontmatter. WHEN TO USE: - Restaurant/person/article auto-detection: auto_template=true, title includes keywords - Explicit template selection: template="tpl-restaurant", customData provided - Manual note creation without templates: auto_template=false, content provided RETURNS: Success message with created note path and applied template name
Create a note using a specific LifeOS template with auto-filled metadata. If YAML rules are configured, consult get_yaml_rules before modifying frontmatter.
Universal listing tool that consolidates folders, daily notes, templates, and YAML properties listing with auto-detection. WHEN TO USE: - Browse vault folder structure: type="folders", path="Projects" - Discover available templates: type="templates" - List daily notes: type="daily_notes", limit=10 RETURNS: Type-specific arrays: folder paths, template list, daily note paths, or YAML property names
Universal search tool with intelligent auto-mode routing. Consolidates all search functionality: basic search, advanced search, quick search, content type search, recent search, and pattern matching. WHEN TO USE: - Find notes by content/metadata: mode="advanced", query="meeting notes" - Recent activity discovery: mode="recent", days=7 - File pattern matching: mode="pattern", pattern="**/*recipe*.md" RETURNS: Array of SearchResult objects with path, title, excerpt, relevance score, and frontmatter metadata TITLE EXTRACTION: Search result titles are determined by priority: 1. YAML frontmatter 'title' field (if present and non-empty) 2. Formatted date for daily notes (e.g., "August 30, 2025" for 2025-08-30.md) 3. Title-cased filename for regular notes (e.g., "My Project Note" for my-project-note.md)
Output schemas not formally defined in JSON Schema. All tools describe return formats in prose ('Array of SearchResult objects') rather than providing structured JSON Schema specifications. This forces LLMs to infer output structure and prevents downstream tool chaining validation.
Tool consolidation creates ambiguous responsibility boundaries. 'search' and 'search_notes' both search notes; 'create_note' and 'create_note_from_template' both create notes. The distinction is unclear from names alone ('mode=advanced' vs separate tool), forcing LLMs to reason about which to choose. Per composition pattern, avoid multiple tools doing the same thing differently.
'search_notes' description is critically brief (11 words, under 20 char threshold for impactful descriptions). Fails to explain why it exists separate from 'search' tool or when to use it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | 1.0.0+ | v1 |
Search notes by content type, tags, category, or date range
Parameter descriptions lack formal constraints. 'contentType', 'category', 'template' parameters across multiple tools reference filter values with no enum definitions or guidance. LLMs cannot determine valid values and will hallucinate. Per pattern, enums should be used for known sets of values.
Tool definitions source is test files (scripts/archived/test-tool-consolidation.js, test-tool-parity.js). These are validation scripts, not the actual server implementation. Cannot confirm these are the actual registered tools in the running server without seeing src/index.ts or src/tools/ registration code.
'customData' parameter in create_note and create_note_from_template is typed as generic 'object' with vague descriptions. No schema for its properties, no guidance on what fields are required per template type. Forces LLM to guess valid fields or requires extra discovery call.
No explicit error handling guidance. Tools provide no recovery instructions (e.g., 'If title already exists, try search() first' or 'Note creation failed; verify folder path exists'). Per pattern, errors must tell LLM what to do next.
Missing idempotency guidance. 'create_note' and 'create_note_from_template' are mutation tools. No documentation of whether calling twice with same input creates duplicates or returns existing note. Agents need to know whether to retry on failure.
Documentation references 'get_yaml_rules' tool in create_note_from_template description but this tool is not in the tools list. Either get_yaml_rules is missing from the server, or the reference is stale. Broken tool references prevent proper tool chaining.