Loading ToolBench
Graph-based memory system for Claude Code using Neo4j
graph-memory demonstrates solid definition quality with well-structured schemas, clear parameter descriptions, and reasonable naming. Both tools are explicitly registered with full input schemas and descriptive text. graph_query provides detailed usage guidance ('Use when you know the entity name...prefer graph_search for natural-language'). graph_relate includes batch mode documentation and idempotency guarantees. However, the server lacks explicit output schema documentation, neither tool documents the structure of returned results (what fields in a node? what properties on edges?). The descriptions are good (128 and 184 chars respectively) but could be more concise per LLM-optimized baselines (50 - 200 chars is ideal; these are at the upper bound). Parameter descriptions are present and typed, though some lack constraint detail (e.g., 'weight' accepts 0.0 - 1.0 but the description doesn't state this range; 'entities' array lacks min/max length guidance). Tool naming is clear and action-oriented (graph_query, graph_relate), and the distinction between the two tools is obvious. No security issues detected in parameter design (no secrets exposed). Error handling is mentioned implicitly (idempotency, batch atomicity) but not explicitly documented as part of the output schema.
Query the memory graph by canonical entity name. Use when you know the entity name or close-to-canonical form (e.g. "Steve", "graph-memory"); for natural-language phrasing or synonyms (e.g. "the knowledge graph project") prefer graph_search. Returns up to `limit` matching nodes plus the edges that connect them within `max_hops`, with per-edge weight and source provenance.
Create or strengthen a relationship between entities. Creates the endpoint entities if they don't exist. Use single mode (from_name/to_name/relation) for one fact at a time. Use batch mode when extracting from a transcript or document — it's atomic, so a partial failure won't leave dangling nodes. Idempotent: re-asserting an existing edge boosts its weight rather than duplicating.
Output schemas not documented. Neither tool specifies the structure of returned results (node fields, edge properties, metadata). LLMs cannot plan downstream tool calls without knowing what data is available.
Parameter constraints underspecified. 'weight' accepts 0.0 - 1.0 (stated in description for graph_relate but not as JSON Schema min/max); 'entities' array lacks minItems/maxItems; 'limit' lacks explicit max bound. JSON Schema constraints are machine-parseable and prevent LLM hallucination of invalid values.
Error handling not documented. The description of graph_relate mentions 'atomic' failure behavior and idempotency, but there is no explicit error response schema or guidance on how LLMs should respond to errors (retryable vs. user-fixable vs. fatal).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Parameter 'context_level' uses an enum, which is good, but the enum values ('minimal', 'full', 'relations-only') lack descriptions explaining the semantic difference between them. LLMs must guess what 'relations-only' returns.