Loading ToolBench
Long term memory server using MCP and Neo4j. Provides tools for storing, retrieving, and managing long-term memories, entities, relationships, claims, and documents in a Neo4j graph database. Designed as a backend for AI agents requiring persistent memory and knowledge graph capabilities.
Server provides 18 well-structured tools with consistent naming (verb_noun pattern: memory_*, graph_*) and complete JSON schemas. All tools have descriptions (avg 85 chars) and typed parameters with defaults. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from visible code; no recovery guidance or actionable error messages. Parameter descriptions lack format constraints (e.g., similarity thresholds, confidence ranges). No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Missing idempotency guarantees for graph operations.
Find claims by semantic search, optionally filtered by entity or status.
Return CONTRADICTS edges involving the given entities (or all if None).
Find documents by semantic search, optionally filtered.
Find entities semantically similar to the query. Optionally filter by node types.
Return Document nodes linked to the given entities via SOURCED_FROM.
Get relationships involving the given entities, with optional multi-hop traversal.
Create a typed edge from a Document to an entity node.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects). Forces agents to guess what data is available after each call, increasing hallucination risk.
Descriptions lack LLM-optimized guidance. Generic descriptions (avg 85 chars) do not explain WHEN to use each tool vs similar alternatives. E.g., memory_recall vs memory_find_similar distinction is unclear. Agents waste reasoning cycles deciding between overlapping tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Store a Claim node and link it to entities via ASSERTS edges.
Record that two relationships contradict each other.
Store or update a Document node (unique by URL).
Create an IS_A edge from child to parent (idempotent). Both entities must exist.
Store a directed typed relationship between two entities.
Update a claim's status (supported, disputed, unverified, retracted).
Insert or update a typed entity node. Deduplicates by semantic name similarity.
Find memories semantically similar to the query.
Recall memories via semantic search, optionally filtered by category or importance.
Return counts of all graph elements (entities, relationships, documents, claims, etc.).
Store a memory. Returns success status and memory_id.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Server clearly distinguishes read-only (FIND, GET, RECALL) from write (STORE, UPSERT, UPDATE) tools, but LLMs cannot see this distinction in the schema. Agents may retry destructive operations, causing duplicate records.
Parameter descriptions lack format constraints. Numeric params (similarity_threshold, confidence, min_importance) have no stated ranges or validation rules. E.g., 'confidence' defaults to 0.8 but no bounds given, LLM could pass 1.5 or -0.5. Descriptions should state: 'Confidence score (0.0 - 1.0, default 0.8)'.
No error handling or recovery guidance visible in tool definitions. If a relationship store fails (entities don't exist, duplicate edge, Neo4j timeout), LLMs have no guidance on what to do next. Error responses should include actionable recovery steps.