Loading ToolBench
An MCP server providing a persistent key-value memory store with semantic search for your agents
Server has well-structured Zod schemas with descriptions for all 9 tools and parameters. Naming follows verb_noun convention (retrieve_, store_, update_, delete_, create_, list_). Descriptions are present and substantive (100-200 chars typical). However, output schemas are not documented, tool implementations exist but return types are not visible in the provided code. Error handling and recovery guidance are absent from descriptions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Semantic search tool lacks detail on similarity scoring algorithm.
Creates a new namespace for storing key-value pairs. Use this before storing items in a new namespace. If the namespace already exists, this is a no-op and returns success.
Deletes a key-value pair from a namespace. Use this to remove data that is no longer needed or to clean up temporary storage.
Deletes an entire namespace and all key-value pairs within it. Use this for cleanup when all data in a namespace is no longer needed.
Lists keys and timestamps for all items in a namespace without retrieving their values. Use this to discover what data is available before retrieving specific items.
Lists all available namespaces. Use this to discover what namespaces exist before retrieving or storing data.
Retrieves a stored value by its key from a specific namespace. Although values are stored as strings, they are automatically parsed and returned with their original data types. For example, JSON objects/arrays will be returned as structured data, numbers as numeric values, booleans as true/false, and null as null.
Output schemas not documented. Tool implementations exist but return types are not visible in source. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot distinguish safe from dangerous operations without explicit hints.
Semantic search tool (retrieve_context_items_by_semantic_search) lacks algorithmic detail. Description does not explain similarity scoring method, embedding model, or when to use vs. key-based retrieval. Similarity_threshold and limit parameters lack guidance on typical values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Retrieves context items using semantic search based on query relevance
Stores a NEW value associated with a key in a specified namespace. IMPORTANT: All values must be passed as strings, but the system will intelligently parse them to preserve their data types. This tool will fail if the key already exists - use update_context_item for modifying existing items.
Updates an EXISTING value associated with a key in a specified namespace. This tool will fail if the key does not exist - use store_context_item for creating new items. All values must be passed as strings but will be intelligently parsed to preserve data types.
Error handling and recovery guidance absent from tool descriptions. No guidance on what to do if a key already exists (store_context_item), key not found (retrieve_context_item_by_key), or namespace not found. Agents cannot self-correct.
No confirmation or dry-run pattern for destructive operations (delete_context_item, delete_namespace). Agents can permanently erase data without safeguards.