Loading ToolBench
AI Memory Bank Management with Enhanced Search - Create semantic-search memory banks from files, directories, text, or URLs with intelligent ranking and filtering.
MemVid MCP Server demonstrates solid foundational work with comprehensive tool schemas and detailed descriptions. All 7 tools have explicit input schemas with type definitions and parameter descriptions. Tool naming follows verb-noun conventions (create_*, search_*, list_*, add_*, get_*, health_*, system_*). However, several issues prevent a higher score: (1) Output schemas are entirely undocumented, no tool specifies what fields or structure it returns, blocking downstream tool composition and LLM planning; (2) descriptions exceed baseline length (194 chars avg), with some verbose by 100%+, e.g. create_memory_bank at ~600 chars includes usage guidance that should be in docs, not in the schema; (3) some parameters lack validation constraints (e.g., memory_bank string in add_to_memory has no length/format restrictions); (4) error handling lacks recovery guidance, tools define what can fail but not how LLMs should respond; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) to classify risk; (6) create_memory_bank and add_to_memory accept WRITE operations but lack dry-run or confirmation patterns for destructive safety.
Append new content to an existing bank without a full rebuild. Use when sources gained new material but most of the bank is still valid — reduces staleness vs recreating from scratch. Does not remove or re-index changed existing chunks; for large rewrites, prefer create_memory_bank again.
Create a semantic-search memory bank from files, directories, text, or URLs. WHEN TO USE: - Corpora outside the current Cursor workspace (notes, other repos, reference docs) — set paths under MEMVID_ALLOWED_PATHS / MEMVID_WORKSPACE_ROOT in server env - Curated subsets you want ranked semantic retrieval over (not keyword grep) - Persistent cross-session knowledge that should not be re-ingested every chat WHEN NOT TO USE (prefer Cursor codebase search / read_file instead): - Files already open in the workspace and likely current - Small corpora where reading 1–3 files directly is faster STALENESS: Banks are a snapshot at creation time. Content on disk can drift until you recreate the bank or use add_to_memory. After large source changes, recreate or incrementally update. URL sources require MEMVID_ALLOW_URL_SOURCES=true (HTTPS only). File/directory paths must be under allowed roots.
Return search results formatted as a single context block for the conversation. Same staleness rules as search_memory. Prefer read_file for live workspace code; use this for pre-indexed corpora (especially outside-workspace knowledge).
Check Python bridge, storage, and server readiness. Run if tools fail or after env changes.
No output schemas documented for any tool. LLMs cannot predict response structure, preventing composition and forcing manual trial-and-error.
Tool descriptions are overly verbose (avg 300+ chars), mixing operational guidance ('WHEN TO USE', 'STALENESS') with schema definitions. This inflates token cost and buries key intent signals.
WRITE operations (create_memory_bank, add_to_memory) lack dry-run or confirmation patterns. Agents could accidentally overwrite or corrupt memory banks.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
List memory banks with metadata (name, description, tags, creation time). Use before search_memory to discover bank names and judge staleness — compare bank age to when source files last changed. If stale, recreate with create_memory_bank or patch with add_to_memory.
Semantic search over pre-built memory banks (meaning-based, not exact keyword match). WHEN TO USE: - Querying indexed corpora, especially outside-workspace or multi-project banks - Finding conceptually related chunks when you do not know filenames WHEN NOT TO USE: - You need the live on-disk file in the workspace RIGHT NOW — read_file/grep instead - No bank exists yet — call create_memory_bank first - Sources changed significantly since the bank was built — recreate or add_to_memory first, then search STALENESS: Results reflect the last index build, not live disk. If answers seem outdated, check list_memory_banks dates and refresh the bank.
Detailed diagnostics for troubleshooting Python path, memory banks dir, and bridge errors.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) to classify risk. Clients cannot distinguish safe tools from destructive ones.
Parameter naming inconsistency: system_diagnostics uses camelCase (includeMetrics, includeLogs) while other tools use snake_case (include_stats, max_tokens). This risks LLM confusion.
Numeric parameters lack explicit min/max constraints in schema. E.g., 'chunk_size' and 'overlap' in create_memory_bank are numbers with no bounds, allowing LLMs to pass invalid values.
Error recovery guidance is missing. Tools define error conditions but do not tell LLMs what to do next (retry, ask user, abort).
No pagination guidance. search_memory accepts top_k (1 - 50) but does not document offset/cursor support. Callers cannot iterate over large result sets.
Nested object parameters lack per-property descriptions. E.g., 'metadata' object in add_to_memory and 'filters' object in search_memory have no documentation of accepted fields.
Ambiguous parameter semantics. 'memory_bank' parameter in add_to_memory and search_memory is described as 'bank name' but not validated, unclear if it accepts display name or internal ID.