Loading ToolBench
Model Context Protocol Server for Markdown-Based Knowledge Management
MindPalaceServer has 4 tools with basic definitions, but significant quality gaps. All tools have descriptions (10-120 chars) and input schemas with type definitions, but descriptions are often generic or underdeveloped. Parameter descriptions are minimal or absent. No output schemas are documented. Error handling is not evident. The write operations (propose_new_knowledge, suggest_knowledge_update) lack idempotency hints, confirmation mechanics, or clear side-effect documentation. Tool naming is verb-forward but lacks clarity on mutual exclusivity and data flow between tools.
Retrieve the full content and metadata of a specific knowledge entry by its entry_id
Propose adding a new knowledge entry. The proposed content MUST contain frontmatter with required fields: entry_id, title, tags, created, last_modified, and status.
Search the knowledge base for relevant entries based on a query string
Suggest updates to an existing knowledge entry. Enforces verification that the entry_id is a valid entry in the knowledge_base/active folder.
Output schemas not documented. No tool returns a documented schema (fields, types, examples), forcing LLMs to infer result structure. Breaks downstream tool composition.
Descriptions are vague or generic. 'Search the knowledge base for relevant entries based on a query string' (80 chars) lacks guidance on when to use this vs get_entry_details, what rank/score is returned, whether pagination is supported, or result count limits.
Parameter descriptions are missing or incomplete. 'top_k' has description 'Number of top results to return (default 5)' but no range constraints (1 - 100?), and no guidance on token cost or context window impact of large result sets.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Destructive operations lack confirmation or idempotency hints. propose_new_knowledge and suggest_knowledge_update modify state but have no tool annotations (destructiveHint), no dry-run support, no documented idempotency guarantees, and no clear error handling for conflicts (e.g. entry_id already exists).
Error handling not evident. No recovery guidance in code. If propose_new_knowledge fails (e.g. invalid frontmatter, entry_id conflict), the tool should return actionable error messages like 'Invalid frontmatter: missing required field "status". Expected format: ---\nentry_id: ...\n---', not generic failures.
Tool composition risks. suggest_knowledge_update requires 'entry_id' (string) and 'existing_content_verified' (boolean). There's no clear guidance on how an agent discovers entry_ids (must call search_knowledge first?), and the boolean flag suggests a verification step, but what does the LLM do if it's false? No downstream recovery path.
Naming ambiguity: propose_new_knowledge vs suggest_knowledge_update both submit changes, but propose goes to a 'review' folder while suggest updates 'active' entries. This is not clear from the names alone. 'propose' and 'suggest' are near-synonyms; LLMs may confuse them. Names should be 'create_knowledge_for_review' and 'update_active_knowledge' for clarity.
Pagination not mentioned. search_knowledge returns 'top_k' results but no next_cursor, has_more, or total_count. If the knowledge base is large, LLMs cannot iterate through all results. This violates the paginated-result pattern and caps the utility of search.