Loading ToolBench
A Model Context Protocol server for managing semantic memory, documents, and spaces with graph-based relationships and interactive UI widgets
Memory-MCP demonstrates solid tool design with consistent naming conventions (verb_noun pattern), comprehensive parameter descriptions, and structured output types. All 13 tools have descriptions and input schemas are visible. However, several tools lack output schema documentation in the source, and some parameter constraints (enums for docType, action) are not formally declared in schemas. UI tools (select_space_ui, guided_save_ui, upload_file_ui, memory_graph_ui) are thin wrappers returning confirmation strings, appropriate for the Apps extension pattern but minimal in substance. Error handling and recovery guidance are not evident in the provided code. The server demonstrates good composition (tools chain well via containerTag/spaceKey) and accepts natural identifiers (space keys, document IDs) rather than opaque system IDs.
Saves new information as a memory ('save', default), or forgets a previously saved memory matching the given content ('forget').
Stores content as a new document in a space (text/Markdown/CSV/PDF in this version — this does not extract memories, call add_memory separately for that). For docType "pdf", content must be the base64-encoded PDF bytes; the text is extracted server-side and stored/returned instead of the binary.
Reads the metadata and available content of a single document.
Opens an editable memory draft form with a space selector before saving.
Lists source documents stored in a space, paginated.
Lists extracted memory entries in a space, paginated.
Output schemas not documented in source code. Tools like whoAmI, listSpaces, getDocument return DTOs (WhoAmIResult, SpaceSummaryDto, DocumentDetailDto) but their field structures are not visible in the provided code. LLMs cannot plan downstream calls without knowing what fields to extract.
Parameter constraints not formally declared as enums. create_document's 'docType' accepts 'text', 'markdown', 'csv', 'pdf' but is typed as free-form string. add_memory's 'action' accepts 'save' or 'forget' but lacks enum constraint. LLMs may hallucinate invalid values.
No error handling or recovery guidance visible in tool implementations. McpExecution.RunAsync wraps calls but error responses are not shown. LLMs need actionable error messages (e.g., 'Space not found. Try listSpaces() to see available spaces.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |
Lists the spaces accessible to the current API key, with the effective access level (the space grant capped by the user's role) and document/memory counts.
Opens an interactive visualization of the memory graph for the active space.
Searches stored memories in a space by semantic similarity, literal keyword, and/or category, optionally including stable/recent profile context. Provide at least one of query/keyword/category.
Opens a picker to choose which of the current API key's accessible spaces is active.
Sets which of the current API key's accessible spaces is the active (default) one.
Opens a local file picker to upload a document (text/Markdown/CSV content in this version).
Returns the authenticated user (id, email, display name, and role: Writer or Reader), the API key in use, its accessible spaces with effective access level, and the active space.
UI tools (select_space_ui, guided_save_ui, upload_file_ui, memory_graph_ui) return minimal confirmation strings. While appropriate for the Apps extension pattern, they provide no structured feedback about what the user selected or uploaded. Downstream tools must be called to retrieve results.
search_memory requires 'at least one of query/keyword/category' but this constraint is enforced server-side (per code comment) rather than declared in the schema. LLMs may call with no parameters and receive a validation error instead of understanding the requirement upfront.