Loading ToolBench
A flexible and extensible framework for building Model Context Protocol (MCP) servers with dynamic tool registration
This server provides 19 tools with explicit schemas and descriptions. Most tools have adequate naming (verb-based) and documented input parameters. However, there are significant gaps in output schema documentation, error handling guidance, and parameter descriptions. Descriptions average 150-200 characters (within acceptable range but some are generic). Input schemas are present and mostly complete, but output structures are not documented. Many tools lack actionable error recovery guidance. The server lacks explicit confirmation patterns for destructive operations despite identifying them as DESTRUCTIVE. Tool composition is reasonable but some tools do overlapping work (delete-prompt, delete-tool, delete-user, remove-user all follow similar patterns without variations).
Add a new prompt to the system
Add a new user
Delete a prompt from the system
Delete a tool
Delete a user
Echo back the input message
Hide one or more tools for the current user
Output schemas not documented. While input schemas are present and mostly complete, there is no documentation of what fields are returned by any tool. LLMs cannot plan downstream calls or extract chaining IDs without knowing the response structure.
Destructive operations (delete-prompt, delete-tool, delete-user, unshare-tool, remove-user) lack confirmation patterns. The reset-api-key tool has a two-step confirmation (userConfirmed flag), but delete operations do not. Agents can irreversibly delete resources without a dry-run or confirmation step.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
List all available prompts for the current user
List all tools
List all users
Remove (delete) a user by email. This action is irreversible. You must confirm with the user that they want to remove the user before actually calling this tool.
Reset a user's API key and email the new key to the user. Always call this tool first with userConfirmed: false (or omitted). Only set userConfirmed: true after the user has explicitly confirmed. For non-admin users, the email field is ignored and your own API key will be reset.
Share a tool with another user (adds to their sharedTools array)
Unhide one or more tools for the current user (removes from hiddenTools array)
Unshare a tool from a user (removes from their sharedTools array)
Update an existing prompt's definition or properties
Update an existing tool's definition or properties
Update an existing user
Retrieve information about a user. If email is omitted, returns the current user's info. Admins get full info for any user. Non-admins get only existence and name for other users.
Error handling guidance missing. Tool descriptions do not explain what errors can occur or how to recover. For example, update-tool accepts arbitrary 'updates' object but does not document validation, conflicting field rules, or rollback behavior.
Generic parameter descriptions. 'updates' object in update-prompt and update-tool is described as 'The fields to update in the tool definition (excluding name)' but does not enumerate valid fields, constraints, or combinations. LLMs cannot validate input without explicit field lists.
Parameter type inconsistency in user management. 'email' parameter descriptions say 'If the email is unknown, use the list-users tool to find a user by name' (update-user, delete-user, remove-user), but also accept direct email input. The guidance is helpful but implies the parameter could be a name, which contradicts the schema type of 'string' with no enum.
Pagination guidance incomplete. list-users, list-prompts, list-tools accept skip/limit but descriptions do not state default limits, maximum results, or whether a total count is returned. Baselines expect max result caps (20-50) and documentation of them.
Overlapping tool names without clear distinction. delete-user and remove-user both delete users; delete-prompt, delete-tool, delete-user all follow identical patterns. No description differentiates delete-user from remove-user (remove-user adds confirmation language in description but no confirm parameter). LLMs may conflate these tools.
Opaque object parameters without schema. 'handler' parameter in add-prompt and update-prompt expects an object with 'type' and 'config' (nested object). The 'config' field accepts any object with no schema definition, leaving LLMs unable to construct valid handlers. No enum of handler types or config examples provided.