Loading ToolBench
MCP server exposing an Obsidian prospect catalog as queryable tools. Reads markdown notes with YAML frontmatter from a vault directory and exposes them to MCP clients (Claude Desktop, Claude Code, etc.) as structured, queryable data without requiring Obsidian to be running.
Server exposes 5 read-only prospect management tools with generally clear naming and reasonable descriptions. All tools have input schemas with type definitions and descriptions. However, output schemas are not explicitly documented in the source, parameter descriptions lack depth (missing format constraints, ranges, and dependency hints), and error handling guidance is absent. Tool names follow verb_noun convention well (list_*, search_*, get_*). Descriptions average ~120 chars, within acceptable range but could be more prescriptive about when to use each tool vs. alternatives.
Fetch a single prospect by slug or name, with full details including the sales hook (if present).
List all prospect categories (unique values of the `category` frontmatter field).
List all site-builder platforms (unique values of the `platform` frontmatter field).
List prospects matching the given filters. All filters are AND-ed together. SAFETY: Notes with stage='do-not-contact' are excluded by default. Pass include_do_not_contact=True to include them (rarely what you want).
Full-text search across prospect names, categories, websites, and notes. Returns matching prospects with relevance ranking.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing what list_prospects, search_prospects, and get_prospect return. The code shows _summarize() and _extract_sales_hook() but these are not exposed as formal output schema definitions.
Parameter descriptions lack actionable constraints. 'limit' is described as '1-200, default 50' but not in the description text itself, it's only in the schema. 'stage' and 'priority' enums are listed but not marked as constrained inputs. LLMs cannot read JSON Schema; they rely on description text.
No error handling guidance. If a prospect is not found, get_prospect returns None silently. If PRAXIS_VAULT_PATH is not set, the server warns but continues. LLMs need explicit recovery hints: 'Prospect not found. Try search_prospects() with a partial name.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Missing dependency hints in descriptions. list_prospects and search_prospects both filter by stage/priority, but descriptions don't explain when to use list_prospects (structured filters) vs search_prospects (full-text). Agents may pick the wrong tool.
list_categories and list_platforms have minimal descriptions (60 chars each). They don't explain when to call them or what structure they reveal. 'List all prospect categories' is too terse; should be 'Call this first to see available categories before filtering with list_prospects().'