Loading ToolBench
MCP server that gives AI coding agents persistent memory across sessions
agent-memcp demonstrates good naming conventions (verb_noun pattern), comprehensive parameter descriptions, and clear input schemas across all 5 tools. Descriptions are well-written and actionable (ranging 150-350 chars). However, output schemas are not documented in the visible source code, and error handling guidance is minimal. The server lacks output field documentation that downstream tools need for chaining, which is a significant gap for a composition-heavy system. Tool definitions are explicitly registered and visible in source, meeting the requirement for direct visibility.
Delete a specific memory by its ID. The project scope must match the scope the memory was stored in. Omit 'project' to delete from the global scope.
List all stored memories, optionally filtered by project scope and/or tags. Returns a summary of each memory (id, key, tags, content snippet). Use project='*' to list across all scopes.
Rename a project scope. All memories belonging to the project are moved to the new name. Returns an error if the project does not exist or if the new name is already in use.
Search for memories using semantic (vector) similarity. The query is embedded and compared against stored memory vectors — results are returned by semantic relevance, not exact keyword match. Use project='*' to search across all scopes (global + all projects). Results are sorted by descending similarity score.
Store a piece of information as a memory. Memories can be project-specific or global. If you provide a 'key' and a memory with that key already exists in the same scope, it will be updated instead of creating a duplicate.
Output schemas not documented in source code. Tools return results but the structure of returned memory objects, field names, and types are not visible in the provided source fragments. This prevents agents from understanding what fields to extract and breaks composition chains.
retrieve_memories returns results 'sorted by descending similarity score' but the similarity_score field is not explicitly documented as part of the output schema. Agents cannot know what fields to expect from semantic search results.
No pagination guidance documented for list_memories or retrieve_memories. While retrieve_memories accepts a 'limit' parameter (default 20, max 100), there is no 'next_cursor' or 'offset' mechanism described, and no indication of what happens when results exceed the limit.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Error responses lack recovery guidance. The store_memory tool description mentions 'if a memory with that key already exists in the same scope, it will be updated instead of creating a duplicate' but does not specify what happens if the upsert fails, what error the agent receives, or what to do next.
delete_memory performs a destructive operation but the tool definition lacks a dry-run option or confirmation step. An agent could accidentally delete memories without a safety mechanism.
rename_project is destructive (moves all memories to new project name) but lacks documentation on what happens if the new_name already exists or if the operation partially fails. Error categorization is missing.
No idempotency guarantee documented. store_memory with a 'key' parameter appears designed to be idempotent (upsert behavior), but this is not explicitly stated. Agents need to know which tools are safe to retry without duplicate side effects.