Loading ToolBench
A local vector memory system for storing, searching, and reconciling chunks of information using semantic embeddings and conflict detection.
Server has 11 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (add_chunk, search, get_chunk, etc.). Descriptions average ~80-120 chars, meeting baseline minimums. All tools have typed input schemas with parameter descriptions. However, output schemas are not documented in the source code provided, critical for LLM planning. Error handling is minimal; no recovery guidance or actionable error messages visible. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Composition is sound (single responsibility per tool), but some tools lack depth in parameter constraints (e.g., top_k has no min/max bounds stated in description).
Add a new chunk of text to the vector store with optional metadata.
Create a backup of the entire vector store.
Check the health of the memory store, including oversized chunks and unresolved conflicts.
Mark a chunk as deprecated without deleting it.
Retrieve a specific chunk by its ID.
Retrieve unresolved conflicts detected during reconciliation.
Retrieve proof of the most recent search operation (for verification).
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does search() return? Does it include chunk_id, text, metadata, similarity_score?). Critical for tool chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (WRITE vs READ_ONLY). MCP spec 2026-07-28 supports tool annotations; omitting them prevents clients from applying safety policies.
Parameter constraints incomplete. search() top_k has no min/max bounds in description (baseline: 1 - 100 stated, but not enforced in schema). list_chunks limit/offset lack explicit ranges. LLMs may pass invalid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
List all chunks in the store with optional filtering.
Restore the vector store from a backup.
Search the vector store for chunks similar to a query using semantic embeddings.
Update the text and/or metadata of an existing chunk.
Error handling and recovery guidance absent. No visible error responses, retry logic, or actionable error messages. If a chunk_id is invalid or a backup path doesn't exist, LLM has no guidance on next steps.
Destructive operations (restore_backup, deprecate_chunk) lack confirmation/dry-run pattern. Agents could accidentally restore wrong backup or deprecate critical chunks without safeguards.