Loading ToolBench
An MCP server for managing memories in a text file
This server has critical definition quality gaps. While all 4 tools are explicitly registered with schemas and names, parameter descriptions are entirely missing, descriptions are vague or incomplete, and output schemas are undocumented. The naming follows verb patterns (append, search, delete, list) which is positive, but parameter validation and error guidance are absent. Tool descriptions average 45 characters, well below the 194-char baseline for A+ tools. No input parameter descriptions exist anywhere in the codebase (0% vs. 100% baseline for A+ tools). The server relies on implicit understanding rather than explicit guidance for the LLM.
Add new memory line(s), use newline to separate
Delete memory entries containing the query
newline delimited list of all memory entries
Return memory entries containing the query
ZERO parameter descriptions across all 4 tools. Every parameter (text, query, query) lacks any description explaining what it accepts, format, constraints, or range. Baseline: 100% of A+ tools describe all parameters.
Tool descriptions are incomplete and vague (30-60 chars vs. 194-char baseline). Descriptions do not explain WHEN to use each tool, what distinguishes them, prerequisites, or actionable next steps for the LLM. For example, search_memory lacks clarity on result limits, pagination, or case-sensitivity.
delete_memory tool lacks warning that operation is DESTRUCTIVE and IRREVERSIBLE. Description does not state this modifies state. No confirmation step, dry-run mode, or guidance on recovery if the user provides wrong query.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
NO output schemas documented for any tool. LLMs cannot plan downstream operations or extract return values without knowing the response structure. Baseline: 100% of A+ tools have documented return types.
String parameters lack constraints. 'text' in append_memories has no max length (risk of OOM or file explosion). 'query' in search_memory and delete_memory lack format/length rules. Baseline: A+ tools specify min/max for all numeric and string parameters.
No error handling or recovery guidance. If a query matches zero entries, what does the tool return? Does delete_memory fail silently or error? Does search_memory return empty list or error? No actionable error messages to guide LLM self-correction.
Tool composition issue: search_memory and list_memory both retrieve memory. Distinction is unclear, why call one vs. the other? Description comments suggest author is unsure ('// PRN no query == ALL? then get rid of list_memory?'). This violates pattern:tool (each tool should do one thing; avoid redundant tools).
list_memory description dynamically includes memory content, mixing tool metadata with runtime state. This is anti-idiomatic and wastes tokens on every ListTools call. Description should be static.