Loading ToolBench
An MCP server over the fleet markdown-memory store, exposing read and careful-write of memories as typed tools.
Memory-mcp provides 9 tools with complete input schemas and descriptions. Naming follows verb_noun convention (memory_search, memory_get, memory_write, etc.). Descriptions are substantive (100-250 chars typical), explaining what each tool does and when to use it. However, several tools lack output schema documentation, parameter descriptions are sometimes generic, and error handling guidance is minimal. The server handles both local markdown and networked semantic backends, but tool composition could be tighter, memory_write and memory_update are separate when they could be unified with optional fields.
Add a memory to the shared semantic store with optional provenance metadata.
Retrieve one memory from the shared semantic store by name and scope.
Return one memory's full frontmatter and body by its name (kebab slug).
Return the MEMORY.md index pointer lines (the human-readable index).
List every memory, optionally filtered by ``type``, sorted by name.
Search the memory store and return ranked hits. Matches ``query`` against each memory's name, description, and body (name matches rank highest, then description, then body; a whole-query phrase match is a strong bonus). Optionally filter by ``type`` (user/feedback/project/ reference). Returns up to ``limit`` hits, each with name/description/type/ path/score, plus the total number matched.
Output schemas not documented. Tools return results but LLMs cannot see field structure (e.g., memory_search returns 'ranked hits' with name/description/type/path/score, but this is only in prose description, not a formal schema). LLMs must infer output shape, risking parsing errors.
Parameter descriptions lack format/constraint details. 'type' parameter in memory_search/memory_list accepts 'user/feedback/project/reference' but description does not enumerate valid values or use enum schema. LLMs may hallucinate invalid types.
Error handling lacks recovery guidance. No indication of what LLM should do if memory_get fails (e.g., 'Memory not found. Try memory_search() with a partial name.'). Agents cannot self-correct on failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Edit an existing memory, preserving any field left unspecified. Only the provided fields change; the rest (including unknown metadata keys) are preserved. Reconciles the single index pointer in place. Raises if the memory does not exist (use ``memory_write`` to create it).
Create a new memory and add its pointer to the index. ``name`` must be a kebab-case slug and is confined to the store root. ``type`` is one of user/feedback/project/reference and ``description`` is a non-empty single line. Refuses to overwrite an existing memory (use ``memory_update``). Optional ``links`` are appended to the body as ``[[name]]`` wiki-links. Returns the written path and indexed status.
Search the shared semantic memory store across one or more scopes.
Naming ambiguity: memory_write vs add_memory, memory_search vs search_memory. Both pairs do similar things on different backends. LLMs must reason about which to call, wasting tokens and risking wrong selection.
Pagination not documented. memory_search and search_memory accept 'limit' but no 'offset' or 'cursor' parameter. If results exceed limit, LLM cannot fetch next page. Large result sets risk context window exhaustion.