Loading ToolBench
Persistent semantic memory + PKM notes integration for LLMs via MCP. Provides memory recall, storage, code indexing, and workflow management. Zero-proxy: API keys never leave your app.
This MCP server exposes 11 tools with reasonable naming (verb-first: search_, fetch_, store_, list_, forget_, map_, get_, checkpoint_) and mostly complete schemas. However, descriptions are inconsistent in depth and quality. Several tools lack parameter descriptions or have vague ones. Output schemas are not documented. Error handling guidance is absent. The server is a wrapper around a remote Cube Memory API, so implementation details are limited, but the tool interface itself has gaps that would confuse LLMs about when to use similar tools (e.g., search_memory vs search_context vs search_code) and what to expect in responses.
Persist a project-scoped work checkpoint before compaction or interruption. Completion requires result evidence, which remains client-reported.
Fetch the full text of specific memories by id (ids come from search_memory).
Close a memory's validity by id (soft): it stops showing up in recall but stays readable by id for audit. Not a physical delete.
Full body of ONE symbol (function/class/method) from an ingested file. Read only the piece you need. Self-heals against the local file if CM_CODE_ROOT is set; always reports the indexing age.
RELATIONSHIPS between symbols: who uses/calls/references a given symbol across the whole project (cross-file). Returns every usage point with file, exact line and the code snippet of that line - like IDE 'find references'. Use when refactoring, renaming, or understanding impact: 'who calls foo?', 'where is X used?'. Self-definitions are excluded.
No output schemas documented. Tools return results but LLMs cannot plan downstream calls without knowing response structure (e.g., does search_memory return 'id', 'memory_id', or 'mem_id'?). This violates pattern:tool and pattern:response-shaper.
Three search tools (search_memory, search_context, search_code) have overlapping purposes. Descriptions do not clearly explain when to use each. LLMs will struggle to disambiguate. search_memory searches memories; search_context searches 'all project context' (vague); search_code searches code symbols. The distinction is unclear.
Parameter descriptions are sparse or missing. 'escopo' in search_memory is described but its enum values ('universal', 'projeto:<id>', 'cena:<id>') are not formally constrained in the schema, they appear only in the description text. LLMs cannot reliably parse prose constraints. Use JSON Schema enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
List stored memories, most recent first.
Skeleton of one ingested code file: every symbol with its line range. Use instead of reading the whole file when you only need to know WHERE to look. Self-heals against the local file if CM_CODE_ROOT is set.
Semantic search inside the project's ingested code symbols (functions/classes/methods). Use for 'where is X implemented', 'which function handles Y'. Returns file path + line range per hit, with the indexing age.
Search all project context, including uploaded documents, notes, memories and indexed code symbols.
Recall relevant memories before responding. Call this first with the user's message. Optional `escopo` narrows the search ('universal' | 'projeto:<id>' | 'cena:<id>', or a list); default = universal + this project.
Save a memory. Point at the source of truth instead of copying it; if it overlaps an existing memory, update that one instead of appending a second copy. Optional `tipo` (semantica|episodica|procedural|preferencia|entidade|projeto|coletiva | 'auto'), `escopo` ('universal' default | 'projeto:<id>' | 'cena:<id>') and `autor_id`.
No error handling guidance. Tools do not document what happens on failure (e.g., invalid memory ID, API timeout, permission denied). LLMs receive raw errors with no recovery path. Violates pattern:recovery-guide.
Tool composition risk: store_memory and checkpoint_work are WRITE operations but lack confirmation/dry-run patterns. Agents could accidentally overwrite memories or corrupt workflow state. Violates pattern:confirmation-request.