Loading ToolBench
Persistent knowledge vault for coding agents — exposes search, store, status, capture, preserve, and get operations. Supports both stdio (local) and streamable-http (remote) transports with bearer token authentication.
Memento Vault exhibits solid schema coverage and well-described tools, but has inconsistent parameter documentation and lacks output schema specifications. 12 of 13 tools have explicit descriptions (90%+). Input schemas are present and mostly complete with type information. However, output schemas are not documented anywhere in the codebase, LLMs cannot predict return structure or plan chaining. Parameter descriptions vary widely in quality: strong examples like memento_search (query, limit, semantic all documented) contrast with memento_status (empty input schema with no docs). Tool naming follows verb-noun convention consistently (search, store, get, capture, preserve, list, delete). No tool annotations (readOnlyHint/destructiveHint) are present despite clear distinctions between read (search, get, list) and write (store, capture, preserve, delete, update_index) operations. Error handling is minimal, no guidance for recovery, no categorization, no examples of expected error responses. Security model relies on server-side config (API keys in env, auth via Bearer tokens in HTTP layer) which is correct, but no per-tool permission scoping is documented. Tool composition is reasonable, search+get+store form a coherent knowledge management chain, but memento_recall and memento_build_tool_context overlap in purpose (both serve context-building for tool execution) and could be consolidated.
Generate a context briefing for the current project and session.
Build contextual information for a specific tool invocation based on vault knowledge.
Capture a raw transcript or session fragment into the vault's fleeting notes.
Analyze vault notes for logical contradictions and consistency issues.
Delete a note from the vault by path.
Retrieve a specific note by path from the vault.
List all notes in the vault with optional filtering.
No output schemas documented for any tool. LLMs cannot predict response structure, plan downstream tool calls, or extract required fields (e.g., returned note IDs, score values, contradiction counts). This violates pattern:tool and pattern:tool-chain, missing documentation of return types prevents proper composition.
memento_status has no input schema (empty dict {}) and minimal description (only visible in Dockerfile comment, not in tool docstring). Cannot determine if this is a health check endpoint or what status it returns. Violates pattern:tool-description baseline of 10-1024 character descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2025-06-18+ | v2 |
Preserve a bundle of code artifacts, transcripts, or other data for long-term archival.
Retrieve memories relevant to a prompt or query in the context of tool execution.
Search the vault for notes matching a query. Supports semantic search, BM25 ranking, and metadata filtering.
Get the health and status of the vault and MCP server.
Write or update a note in the vault. Accepts markdown with YAML frontmatter.
Reindex the vault's search database, scanning for new or modified notes.
Tool annotations are completely absent. No readOnlyHint on read-only tools (search, get, list, recall, briefing), no destructiveHint on destructive tools (delete_note, preserve), no idempotentHint on safe-to-retry operations. Current MCP spec (2026-07-28) makes these annotations standard for agent decision-making. This is a spec alignment gap.
memento_recall and memento_build_tool_context both accept (prompt, cwd, session_id) and return context for tool execution. They appear to serve the same purpose with different naming. Per pattern:tool, each tool should do exactly one thing; overlapping tools confuse LLM reasoning. Consider consolidating or clarifying the distinction in descriptions.
No error handling guidance visible in tool descriptions or code samples. Patterns like recovery-guide (tell LLM what to do next) and error-classification (retryable vs user-fixable) are absent. If a search returns no results or a note deletion fails, LLMs have no structured guidance on recovery.
memento_list_notes and memento_search both search the vault with similar filtering. memento_list_notes filters by project/type/tags; memento_search filters by query/score/detail_level. Slight ambiguity on when to use each. Per pattern:tool, avoid multiple tools doing the same thing differently, the LLM wastes reasoning cycles deciding between them.
memento_store accepts a 'certainty' parameter (integer 1-5) but no description explains the scale or how LLMs should reason about it. Per pattern:constrained-input and review:param-validation-rules, enum constraints and value meanings must be explicit. Should include: 'Confidence scale: 1=uncertain/speculative, 5=definitive/proven. Affects search ranking.'
memento_preserve accepts a 'bundle_path' parameter but does not document expected directory structure or file types. Per pattern:tool-description, parameters must include format expectations. Should specify: 'Path to directory or .tar/.zip archive. Directory must contain code artifacts, transcripts, or config files.'