Loading ToolBench
Self-evolving personal knowledge graph for Claude Desktop. MCP server with semantic search, memory storage, and web UI for managing interconnected notes and insights.
KARP Graph Lite has well-structured tool definitions with complete schemas and descriptions for all 10 tools. Tool names follow verb_noun convention (remember, recall, forget, update, connect, search, list, propose_node_type, snapshot). Descriptions are substantive (100-200 chars typical), explaining WHAT each tool does and WHEN to use it. Input schemas are properly typed with required fields declared. However, several tools lack output schema documentation, parameter descriptions are sometimes generic, and error handling guidance is minimal. Tool annotations (readOnlyHint, destructiveHint) are present and correctly applied. No critical security issues detected in parameter design, no secrets exposed as params. The 'list' tool has good pagination support (limit, offset, sort). Overall solid foundation but missing output documentation and recovery guidance that would elevate this to 75+.
Create a named relationship between two nodes. Examples: "led_to", "contradicts", "part_of", "inspired_by", "blocks".
Delete a node from the knowledge graph by ID. This is permanent.
Knowledge graph health: node counts by type, database size, embedding coverage, available types, pending proposals, snapshot count.
Browse nodes by type, tags, or date. Returns summaries, not full content. Use recall or search for content-based lookup.
Propose a new custom node type. The user will review and approve it in the web UI before it becomes available. Describe the fields this type needs.
Semantic search across your entire knowledge graph. Finds nodes by meaning, not just keywords. Use this to find relevant memories, decisions, insights, or any stored knowledge.
Output schemas not documented. Tools return results but LLMs cannot see what fields to expect (e.g., does 'remember' return {id, node, timestamp}? does 'recall' return {results: [{id, summary, score}]}?). This forces LLMs to guess field names for downstream chaining.
Error handling lacks recovery guidance. No tool description explains what to do if a call fails (e.g., 'If node not found, try recall() to search by content' or 'If connection fails, verify node IDs exist'). Agents cannot self-correct.
Parameter 'type' in remember/recall/search/list is ambiguous. Description says 'Node type' but does not enumerate valid types or explain how custom types work. LLMs cannot know if 'type' accepts 'memory', 'todo', 'custom_recipe', or arbitrary strings.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Store a memory, note, decision, todo, insight, dev_session, changelog, or any custom type in your knowledge graph. Returns the created node with its ID.
Keyword/exact match search across node summaries and details. Faster than recall but less intelligent. Use recall for semantic search.
Create a backup snapshot of the entire knowledge graph. Recommended before major changes.
Edit an existing node. Only provided fields are updated — everything else stays the same.
kg_status tool name is vague. 'kg_status' does not clearly signal what it does. Better names: 'get_knowledge_graph_stats', 'describe_graph_health', or 'list_graph_metadata'. Current name requires reading description to understand purpose.
Destructive operations (forget, snapshot) lack confirmation/dry-run pattern. No mention of whether these support a 'confirm' step or dry-run mode. Agents could accidentally delete nodes or create unwanted snapshots without safeguards.