Loading ToolBench
Entity-anchored graph memory with vector search and community detection for Claude Code
MemoryGraph demonstrates solid definition quality with complete JSON schemas, clear descriptions, and well-structured parameters across all 10 tools. Tool names follow verb_noun convention (memory_store, memory_recall, memory_relate). All tools have descriptions (avg ~180 chars, within 10-1024 baseline). Parameters include type constraints, enums, and min/max bounds. However, output schemas are not documented, LLMs cannot predict response structure for planning downstream calls. Error handling guidance is absent; tools lack recovery hints. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Parameter descriptions are adequate but could be more prescriptive about format/constraints.
Show Louvain community clusters — groups of entities that are closely related. Optionally force a fresh cluster detection pass.
Retrieve full context for an entity — its memories, relations to other entities, and community cluster membership. Use this to understand everything known about a specific entity.
List known entities, optionally filtered by name query or entity type. Returns paginated results.
Soft-delete a memory. The memory is marked as deleted and excluded from recall, but remains in the database for audit purposes.
Run maintenance operations: decay stale memories, prune low-salience memories below the threshold, and optionally refresh community clusters.
Semantic search across stored memories with salience-weighted ranking. Returns memories most relevant to the query, scored by a combination of vector similarity (60%) and salience (40%). Optionally expands results through entity cluster associations.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for planning multi-step workflows. E.g., memory_recall returns what fields? Does it include entity_id for chaining to memory_context?
No error handling guidance. Tools lack recovery hints (e.g., 'If memory not found, try memory_recall() to search by content'). Agents cannot self-correct on failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are classified by risk (WRITE, READ_ONLY, REVERSIBLE) in metadata but not exposed via MCP annotations. Agents cannot infer safety properties.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
Boost the salience of a specific memory. Reinforcement increases the memory importance score, making it more likely to surface in recall and slower to decay.
Create or strengthen a typed relation between two entities. If the relation already exists, its weight is updated. Relations are directional (source -> target).
Return system statistics including total entities, memories, relations, clusters, database size, and average salience.
Store a memory anchored to one or more entities. Memories are the core unit of knowledge — each one is a piece of information linked to the entities it concerns. Duplicate content is detected automatically.
Pagination not documented for list tools. memory_entities accepts limit/offset but no indication of total count or next_cursor in response. Large result sets risk context window exhaustion.
Parameter descriptions lack format/constraint details. E.g., memoryId is 'format: uuid' in schema but description says only 'The UUID of the memory'. LLMs may not parse JSON Schema format fields; descriptions should state 'UUID format (e.g., 550e8400-e29b-41d4-a716-446655440000)'.