Loading ToolBench
MCP server providing calculator, datetime, and note management tools
MCPllmContext exhibits significant quality gaps across naming, descriptions, and output schema documentation. Tool names lack action verbs and clarity. Descriptions are present but generic and lack context about when to use tools, prerequisites, and what they return. Parameter descriptions exist but are minimal. Output schemas are completely undocumented, responses are unstructured text rather than typed objects. Error handling provides no guidance for recovery. The calculator tool has a critical security flaw (uses Function() which is unsafe for untrusted input). No input validation, no pagination support, and all tools return plain text responses instead of structured data.
Math expression to evaluate
Date format (short or long)
Retrieve a note by title
List all saved notes
Save a note with title and content
CRITICAL SECURITY: calculate tool uses Function() with user-supplied input, enabling arbitrary code execution. This is a remote code execution vulnerability.
Tool names lack action verbs. 'calculate' should be 'eval_math' or 'compute_expression'; 'current-date' should be 'get_current_date'. Names must start with clear action verbs (get_, list_, create_, update_, delete_, search_, compute_) so LLMs infer intent before reading descriptions.
Output schemas are completely undocumented. All tools return unstructured plain-text responses in MCP content format. LLMs cannot plan multi-step workflows or extract typed fields for downstream tools. Responses should return structured objects with explicit field types (e.g., {result: number, expression: string} for calculate).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Descriptions lack context about when to use tools and what they return. For example, 'Math expression to evaluate' does not explain what input formats are accepted, what the return value represents, or when to use this vs. other computation tools. Descriptions should be 50-200 characters and answer: What does it do? When use it? What does it return?
No error recovery guidance. When get-note fails with 'Note not found', it does not suggest calling list-notes first. Error messages should guide LLMs toward recovery: 'Note "X" not found. Call list-notes to see available notes.'
save-note and get-note do not state they modify state or that they operate on in-memory storage with no persistence. Descriptions must clarify state-changing operations and any limitations (e.g., 'Saves note to in-memory storage; data is lost on server restart').
list-notes returns a plain-text string instead of a structured array. Output should be {notes: [{title: string, content_preview?: string}], total: number} to enable LLMs to iterate, filter, or fetch specific notes without text parsing.
No input validation on note title or content. No maximum lengths. An LLM could pass a 1MB content string, exhausting memory. Should validate: title 1-256 chars, content 1-10000 chars, and return 'Title too long: max 256 chars' errors.
current-date format parameter description repeats the enum values instead of explaining use cases. Should be: 'Output format: "short" for MM/DD/YYYY, "long" for full date-time string with time. Use "short" for calendar context, "long" for logging.'