Loading ToolBench
A Model Context Protocol client implementation with multiple CLI variants and UI clients for integrating MCP servers with LLM providers
This server exhibits severe definition quality issues across nearly all dimensions. Source code inspection reveals tool definitions are registered but lack documented schemas, descriptions are minimal or absent, and parameter specifications are either missing or inferred from code structure rather than explicit registration. The 17 tools span multiple identical implementations (getNumber, addTodo, getTodoList, saveWorkHour, getWorkList, addTask appear twice across different package directories), suggesting either duplication without clear purpose or incomplete refactoring. Without access to actual tool registration code (only package.json and file structure visible), tool schemas cannot be verified. Descriptions visible in code are generic and under 20 characters. No evidence of parameter type definitions, enum constraints, output schemas, or error handling guidance.
All tools lack visible input schemas. No JSON Schema declarations found in provided source. Tool definitions are inferred from file paths only, not from explicit registration code.
Tool descriptions are missing or not visible in provided source code. Cannot verify whether descriptions meet the 10 - 1024 character baseline or explain WHAT the tool does, WHEN to use it, or any prerequisites.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Parameter descriptions are not visible. Cannot verify whether each input parameter has a description explaining what it controls, expected format, range, or allowed values.
Duplicate tool definitions appear across mcp-cli-3 and mcp-cli-6 (getNumber, addTodo, getTodoList, saveWorkHour, getWorkList, addTask repeat). This suggests either incomplete refactoring, undefined composition strategy, or unclear responsibility boundaries. LLMs will conflate identical-named tools and fail to distinguish which implementation to use.
Tool names like 'addItemPrice', 'addItemMail', 'addItemCsv' use noun_noun or compound noun patterns that obscure the action. Preferred naming: 'add_price_item', 'send_mail_item', 'write_csv_item' or clearer verb_object forms. Current names make it unclear whether the tool is creating an item with a price, or adding an existing item to a price list.
No output schemas documented. Cannot verify whether tools return structured results, what fields to expect, or how downstream tools can chain results. This breaks tool composition.
No evidence of error handling guidance. Cannot verify whether errors are categorized as retryable, user-fixable, or fatal, or whether recovery suggestions are provided.
sendMail tool exposes email delivery without visible confirmation or dry-run pattern. Cannot verify whether this destructive operation has guards against accidental mass emails or retry loops that cause duplicates.