Loading ToolBench
A Rust-based Model Context Protocol (MCP) server implementation with modular architecture supporting tools and resources
This server has fundamental structural issues that prevent it from meeting production quality standards. Tool definitions lack critical components: descriptions are extremely generic and fail to guide LLM tool selection, input schemas are either missing or not visible in the source code, parameter descriptions are minimal, and error handling provides no recovery guidance. The server conflates MCP protocol messages (initialize, ping) with user-callable tools, violating the MCP specification. Six 'tools' are listed, but only 2 are genuine domain tools (tools/call, tools/list); the remaining 4 are framework artifacts that should not be exposed as tools.
Initialize the MCP server with client protocol version and receive server capabilities
Server ping/heartbeat to verify server is responsive
List available resources with optional cursor-based pagination
Read a specific resource by URI
Call a tool by name with provided arguments
List available tools with optional cursor-based pagination
Protocol messages (initialize, ping) exposed as tools. MCP spec dictates these are handled by the server internals, not called by clients as 'tools'. This violates protocol semantics and confuses clients.
No visible input schemas for any tool. Code references 'schemars' and 'RootSchema' in domain/src/entity/tool.rs, but no actual schema definitions are shown for tools/call, tools/list, resources/list, or resources/read. Scoring rubric requires schema presence: without visible schemas, schema scores are 0.
Tool descriptions are trivial (10-30 chars). 'List available tools with optional cursor-based pagination' (67 chars) is minimal. Guidelines require 50-200 chars with WHAT it does, WHEN to use it, and key details. No description explains why an LLM should call this tool vs a similar one.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 24 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
tools/call parameter 'arguments' lacks description. Name 'arguments' is ambiguous, does it accept JSON, a string, an array? LLMs cannot infer parameter semantics from names alone. Every parameter must have a non-empty description.
Error handling is missing recovery guidance. Domain code defines ToolError::UnknownTool(String) but no response shows how to guide an LLM, 'Unknown tool: foo. Available tools: [list shown]. Call tools/list to discover.' This pattern is absent.
No parameter constraints visible. 'cursor' parameter (tools/list, resources/list) has no description of format, length, or valid values. 'name' parameter (tools/call) has no enum or validation hints. Free-form parameters invite LLM hallucination.
Output schema not documented for users. domain/src/entity/tool.rs defines ListToolsResult, CallToolResult, but this schema is never described in the tool metadata. LLMs cannot plan downstream calls or extract return data without knowing the output shape.
resources/read expects a 'uri' parameter with minimal description. No format hint: is it 'file:///path', 'http://...', or 'resource://...'? Without examples or a pattern, LLMs guess wrong.