Loading ToolBench
Persistent memory MCP server — self-growing knowledge graph without MCP sampling, poisoning quarantine: bitemporal facts, sqlx-migrate, BM25+MMR+OOD hybrid retrieval, graph metrics, conformal prediction, Hebbian/BCM learning, project scoping, tamper-evident audit chain (21 CFR Part 11-oriented), tree-sitter codegraph, git-native sync hooks. Rust + PostgreSQL + pgvector.
MemoryIndustry presents 26 tools with mixed definition quality. Strengths: most tools have descriptions (19-50 words typical) and formal enum constraints on action parameters. Critical weaknesses: (1) output schemas are almost entirely undocumented, no visible return type specifications for any tool; (2) parameter descriptions often lack detail about format, constraints, and dependencies; (3) sensitive operations (cuba_forget, cuba_secure) lack confirmation/dry-run patterns; (4) several tool names are domain-specific jargon ('cuba_*') that don't follow verb-noun conventions, reducing clarity for LLMs unfamiliar with the knowledge-graph domain. Parameter validation is present but not richly described. Tool composition is reasonable (single responsibility mostly), but LLM-facing descriptions need enhancement for action guidance and error recovery.
Create, get, update, delete entities in the knowledge graph
Append-only audit log handler for tamper-evident event recording with hash chain (21 CFR Part 11-oriented)
Recompute abstention threshold from live corpus using conformal prediction
Proxy to invoke any other cuba tool by name with arguments
Parse source code (tree-sitter: Rust, Python) into entities and relations graph
Add, list, batch_add, delete observations for entities with bitemporal fact tracking
Get dashboard summary of graph state: entity count, observation count, graph metrics at a glance
Output schemas completely undocumented: no tool documents what it returns or the structure of response fields. LLMs cannot plan downstream calls or extract specific data.
Tool names use domain-specific prefix 'cuba_*' without leading action verbs (create, get, update, delete, search). 'cuba_alma' is opaque; 'get_entity' or 'manage_entity' would be clearer. LLMs cannot infer intent from the name alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Find and merge entities that are the same concept under different names
Health check: schema validity, embedding dimension, config coherence, stale processes
Retrieval benchmark: nDCG@10, MRR, recall metrics (read-only evaluation)
Export knowledge graph as Obsidian vault with markdown hierarchy
Hybrid search (BM25+MMR+OOD) with optional date range filtering and reranking
Permanently delete an observation from the graph with audit trail
Graph metrics and analysis: closeness, harmonic, k-core centrality, community detection
Optional FalkorDB/Neo4j projection: status check and reconciliation with PostgreSQL as source of truth
Install git hooks for automatic sync export/import on commit/checkout
Auto-link entities by NPMI co-occurrence in the corpus
Select and configure a chat LLM (DeepSeek, Qwen, Ollama, etc.) with saved config
Download embedding, NLI and reranker ONNX models with ONNX Runtime
Session-start context injection for working memory and episodic memory retrieval
Create non-superuser cuba_app role with RLS enforcement and append-only audit guarantee (21 CFR Part 11)
Wire this server into MCP clients; setup check audits client configurations
Export graph-derived procedures as Claude Code skills with source credibility scoring
Git-friendly export/import of graph with diff and status commands
List and search all available tools with optional detail level (names, summary, full)
Consolidation and maintenance operations: reembed, decay, autolink, backfill, PageRank
Destructive tools lack confirmation/dry-run patterns. cuba_forget (permanent deletion with GDPR compliance) and cuba_secure (role creation affecting access control) should support a dry-run or multi-step confirmation before execution.
Parameter descriptions lack format/constraint details. E.g., cuba_faro 'from_date' and 'to_date' state 'ISO 8601 date' but don't clarify if partial dates (2024-01) are accepted, or if time zone matters. No min/max numeric bounds stated for 'limit' or 'offset' parameters across tools.
Tools with array parameters (cuba_cronica.observations for batch_add, cuba_eval.queries) do not document the schema of array elements: required fields, types, constraints. LLMs must guess structure.
cuba_dashboard and cuba_doctor have NO input schema (empty {} input). Their output structure is not documented. Unclear what these tools return or how to use the results for follow-up actions.
Error handling is implicit. No tool description documents what errors can occur, when to retry, or which errors are user-fixable vs. fatal. E.g., cuba_alma update might fail if entity doesn't exist, but the LLM is not told to call cuba_alma get first.
cuba_call is a meta-tool that proxies any other cuba tool. This breaks discoverability and error handling, LLMs cannot reason about what cuba_call will do without inspecting the 'tool' and 'args' parameters at runtime. High risk of hallucinated tool names and invalid arguments.
cuba_llm tool accepts 'api_key' as a parameter. Secrets must never be exposed in tool parameters, they are logged and stored in traces. Use server-side environment variable injection instead.
Parameter names are inconsistent. 'entity_name' in cuba_alma, 'session_id' in cuba_recall, but no clear pattern. Batch operations (cuba_cronica.batch_add) use 'observations' array but single operations use scalar 'content', inconsistent naming inflates cognitive load.
No pagination guidance in descriptions for list/search tools. cuba_faro supports limit/offset but does not document max_limit, whether results are deterministic across repeated calls, or how to iterate through all results.