Loading ToolBench
MCP server for memory management and retrieval with PostgreSQL backend, vector embeddings, and graph-based memory relationships
engram-go provides 26 memory-management tools with consistent naming (memory_* prefix) and reasonable descriptions (avg ~120 chars). All tools have input schemas with typed parameters. However, descriptions lack LLM-optimized guidance on WHEN to use each tool vs. alternatives, parameter descriptions are generic ('Project namespace to scope this call to'), and output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. Tool composition is reasonable but some tools overlap (memory_query vs memory_recall vs memory_explore) without clear disambiguation. Security: no visible credential injection, but audit/permission patterns are absent.
Create a cross-project reference relationship from a memory in the calling project to a memory in another project
Group memories by dimension (tag, type, or failure_class) and return counts with oldest/newest timestamps
Retrieve context from memories and synthesize an answer using Claude with RAG
Audit memory operations and changes with optional filtering
Create a relationship between two memories with optional relation_type and strength
Merge near-duplicate memories to reduce redundancy using bigramJaccard similarity and optional Claude review
Update the content, tags, or importance of an existing memory
No output schemas documented. LLMs cannot infer what fields each tool returns, forcing them to guess downstream field names and risk broken tool chains.
Overlapping tool semantics without clear disambiguation. memory_query, memory_recall, and memory_explore all search memories but differ in subtle ways (limit vs top_k, mode vs detail). Descriptions do not explain when to use each.
Generic parameter descriptions. 'Project namespace to scope this call to. Defaults to default when omitted.' appears on all 26 tools but does not explain what a project is, when to use it, or how it affects results.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Diagnostic recall with evidence building for conflict detection and source validation
Graph neighbourhood explorer that returns connected memories with relationship types, directions, and strength scores
Advanced graph exploration with iterative scoring and optional scope constraints
Export memories to a file in JSON or other formats
Record positive reinforcement for recalled memory IDs with optional event_id and failure_class
Fetch detailed information about a specific memory by ID with optional detail level
Delete a memory by ID
Import memories from a file in JSON or other formats
Ingest documents from local files or URLs with optional chunking and embedding
List memories with optional type and tag filters
List projects and their memory counts
Simplified wrapper over memory_recall for querying memories with optional limit (maps to top_k, defaults to 5) and project
Query document spans with optional regex or substring filters
Simplified wrapper over memory_store for storing content with optional project, memory_type (defaults to 'context'), and importance (defaults to 2)
Retrieve memories matching a query with optional filters, top_k limit, and detail level
Get status and statistics for the memory system in a project
Lightweight liveness probe with 2s internal timeout for health checks
Store a memory with content, optional tags, memory_type, importance, and project
Adjust memory importance weights for ranking and recall prioritization
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next (e.g., 'Memory not found, try memory_list() to see available IDs').
Destructive operations (memory_forget, memory_consolidate) lack confirmation or dry-run support. Agents can permanently delete memories without a safety gate.