Loading ToolBench
MCP Server for searching Obsidian vault notes using ChromaDB vector database. Provides semantic search capabilities with snippet and full-article retrieval modes.
The server provides two tools with clear verb-based names (search_snippets, search_full) and basic JSON schemas. However, there are significant gaps in output schema documentation, parameter descriptions lack depth, and error handling is minimal. Parameter descriptions exist but are terse (6-10 words), well below the 72-char baseline. No output schema is documented for either tool, forcing LLMs to infer the structure of results. Error messages are generic ('Error searching snippets: {e}') with no recovery guidance. The server lacks parameter validation constraints (e.g., limit bounds) and does not explain when to use search_snippets vs search_full beyond content granularity.
Search for relevant notes and return full article content
Search for relevant chunks/snippets from Obsidian notes
No output schema documented for either tool. LLMs must infer that search_snippets returns {chunk_id, content, metadata, distance} and search_full returns {file_path, title, full_path, content, relevance_score}. This forces LLMs to guess field names for downstream processing.
Parameter descriptions are terse (6-10 words). 'Search query string' and 'Maximum number of results to return' lack guidance on query syntax, acceptable value ranges for limit, or when to increase limit beyond the default 10. Baseline: 72 chars per param description.
No input validation constraints on 'limit' parameter. Code returns empty list if query fails, but LLMs have no hint that limit should be 1 - 100 or that requesting 0 or negative values is invalid. Baseline: numeric params should specify min/max.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Error handling returns generic TextContent responses with no recovery guidance. 'Error searching snippets: {e}' is useless to an LLM, no indication whether to retry, adjust the query, or check database status. No distinction between retryable (network), user-fixable (empty results), or fatal (DB connection) errors.
Tool descriptions lack WHEN guidance. Both tools search the same database; the description should explicitly state 'Use search_snippets for focused context (sentence/paragraph level); use search_full when you need the complete article.' Currently, LLMs must infer this from names alone.
No pagination support documented or implemented. Both tools apply a limit but return no cursor, offset, or total_count. If limit=10 and there are 50 matching articles, the LLM has no way to fetch the next page. Baseline: tools returning lists should support pagination.