Loading ToolBench
A Rust-based MCP server that manages sessions with registered model handlers and processes requests via HTTP
The server defines 4 tools with partial schemas and minimal descriptions. All tool names follow verb_resource convention (session.create, session.generate, session.close, models.list), which is good. However, descriptions are extremely brief (10-30 chars), most parameter descriptions are missing, and output schemas are not documented. Input schemas are present in the source but lack depth. Error handling exists but provides generic error codes without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in the brief. The codebase shows custom HTTP parsing rather than a mature MCP framework, and state is managed via Arc<Mutex<>> rather than stateless request handling.
Lists all available models registered on the server
Closes an active session and removes it from the server
Creates a new session with a specified model
Generates a response from a model within an active session given a prompt
Tool descriptions are critically short (10 - 30 characters) and lack context for LLM selection. 'Creates a new session with a specified model' does not explain WHEN to use this vs alternatives, what prerequisites exist, or what the session is for.
Parameter descriptions are mostly absent. The 'model' parameter in session.create has a description, but 'prompt' in session.generate lacks any explanation of expected format, length limits, or constraints. 'session_id' parameters have no descriptions at all.
Output schemas are not documented. The response structure (e.g., what fields session.generate returns) is inferred from code but not exposed in tool definitions. LLMs cannot plan downstream tool calls without knowing what data they receive.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 14 | - | v1 |
Tool annotations (readOnlyHint/destructiveHint/idempotentHint) are absent despite clear risk classifications in the spec (READ_ONLY for create/generate/list, REVERSIBLE for close). Adding these as JSON Schema hints would help LLMs understand safety properties.
Error responses return only error codes (-32602, -32603) without recovery guidance. When a session is not found or a model is unavailable, the LLM receives no hint about what to do next (e.g., 'Try models.list() to see available models').
No pagination or result limits documented. models.list has no explicit limit or pagination strategy. If the server exposes many models, this could return enormous lists that blow the LLM context window.
State is managed via Arc<Mutex<>> (stateful sessions). The MCP protocol (as of 2026-07-28) emphasizes stateless request handling with _meta and per-request context. Reliance on server-side session storage complicates load-balancing, recovery, and testing.