Loading ToolBench
Comprehensive Deno-based library for building MCP servers with tool registration, workflow management, plugin systems, and multi-transport support (stdio, HTTP).
This is a Deno-based MCP server library with 8 tools spread across core functionality and examples. Most tools have basic schemas and descriptions, but quality is inconsistent. Core tools (echo, get_server_status) are trivial; example tools (query_customers_example, create_order_example) show better schema depth with nested objects and constraints. However, critical gaps include: (1) tool definitions appear to be inferred from the listing rather than directly visible in source code (no explicit tool registration shown), (2) descriptions range from 10-200+ chars but many lack actionable context for LLM selection, (3) parameter schemas are present but lack validation rules in descriptions (e.g., userId is required but unmarked; filters object structure is documented in schema but not in description text), (4) no visible error handling guidance or recovery suggestions, (5) test_sampling and test_elicitation expose internal MCP mechanics as user tools rather than internal implementation details, (6) no tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications. The example tools show promise with detailed nested schemas, but the core tools are placeholder-grade.
Create new orders in ExampleCorp system with comprehensive validation.
Simple echo tool that returns the provided message
Get information about ExampleCorp API connectivity and available operations.
Retrieve current status and tracking information for ExampleCorp orders.
Get server status and statistics
Search and retrieve customer data from ExampleCorp API with OAuth authentication.
Test elicitation tool that makes a request to the MCP client for user input/approval
Tool definitions inferred from listing rather than explicitly visible in source code. No clear tool registration pattern shown (e.g., server.tool() or toolRegistry.register()). This prevents verification of actual schema compliance and caps per-tool scores.
test_sampling and test_elicitation are protocol testing tools, not user-facing agent tools. Exposing them to agents violates pattern:tool (each tool should do exactly one business thing). These should be internal debug utilities or removed from the public tool list.
Output schemas not documented for any tool. LLMs cannot plan multi-step workflows or extract returned IDs for downstream tool calls without knowing what fields are returned. For example, create_order_example likely returns an order_id, but this is not documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Test sampling tool that makes a request to the MCP client for text generation
No error handling guidance in tool descriptions. Tools lack recovery hints like 'Try search_customers() first if customer not found' or classification of errors as retryable vs user-fixable. Agents cannot intelligently handle failures.
Tool annotations missing: no readOnlyHint or destructiveHint visible in definitions. create_order_example is marked WRITE but the tool definition itself lacks an explicit 'destructive: true' or similar annotation. Agents cannot understand side effects from the tool definition alone.
userId parameter appears in three example tools but is inconsistently documented. In query_customers_example it's marked required; in others it's unclear if required or optional. This inconsistency will confuse agents and cause tool failures.
Parameter requestedSchema in test_elicitation is a JSON string, forcing LLMs to construct raw JSON inline. This violates pattern:constrained-input, use typed objects instead, or at least provide an enum of valid schema names.
Descriptions for simple tools (echo, get_server_status, get_api_info_example) are vague and under 100 chars, failing to explain WHEN to use them or what they return.
create_order_example exposes internal address/shipping structure but lacks guidance on what happens if an address field is invalid or shipping fails. No error classification or recovery suggestions.
No tool composition guidance. If query_customers_example requires userId for OAuth, and that's obtained from an auth tool, the description should hint at this dependency. Instead, the parameter is presented in isolation.