Loading ToolBench
A fast, ergonomic MCP (Model Context Protocol) framework for Rust inspired by Python's fastmcp
FastRMCP provides a Rust framework for building MCP servers with macro-based tool registration. Analysis of 14 tools across examples (complete, middleware, subscriptions) reveals consistent but minimal quality. Tool names follow verb_noun patterns adequately (add, multiply, greet, calculate_stats). However, descriptions are universally brief (10-40 chars), far below the 50-200 char baseline for LLM-optimized tools. All tools have input schemas with type definitions, but parameter descriptions are either missing entirely or extremely terse (5-10 chars). The framework supports multiple transports (STDIO, SSE, WebSocket) and includes middleware/subscription capabilities, but the example tools are toy implementations that do not demonstrate production-grade patterns like pagination, error recovery, permission gating, or comprehensive descriptions.
Add two numbers
A calculation tool to demonstrate middleware with different operations
Calculate statistics
Count words
Calculate factorial
A simple greeting tool to demonstrate middleware
Create a greeting
Increment the counter
Descriptions critically short, most tools have 10-35 char descriptions, far below 50-200 char baseline for LLM semantic understanding. Examples: 'Add two numbers' (15 chars), 'Calculate factorial' (20 chars), 'Increment the counter' (20 chars). At this brevity, LLMs cannot reliably select the right tool or understand dependencies and preconditions.
Parameter descriptions missing or absent for majority of tools. For 'add' tool: 'a' and 'b' params have descriptions 'First number' and 'Second number' (13-14 chars each), providing minimal context. For 'calculate_stats': 'numbers' param has only 'List of numbers' (15 chars), no guidance on range, format validation, or max size.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | <=2025-11-25 | v2 |
Check if a number is prime
Multiply two numbers
Reset the counter
Reverse a string
Get subscription statistics
Convert to uppercase
No output schemas documented. Tools define input schemas (required by MCP), but no examples or descriptions of return values provided in source. LLMs cannot plan downstream composition without knowing what fields to expect. Pattern baseline: 100% of A+ tools have documented return types.
No error handling patterns implemented. Tools provide no error recovery guidance, categories (retryable vs fatal), or actionable messages. Example: if 'factorial' receives a negative number, server likely returns a generic error rather than 'Invalid input: n must be non-negative (received -5). Try n >= 0.'
No parameter constraints (min/max, enum, regex, format) enforced in schemas. Example: 'calculate' operation parameter is bare 'string' with description 'Operation to perform (add, subtract, multiply, divide)', should be an enum constraint to prevent LLM hallucination (e.g. 'power', 'modulo').
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. 'increment_counter' and 'reset_counter' are write operations but not marked; 'subscription_stats' is read-only but unmarked. Agents cannot distinguish safe retry candidates from destructive calls without annotations.
No composition support demonstrated. Tools are isolated examples (math, string, counter) with no chaining. Real-world tools should return IDs/references enabling downstream calls. Example: if 'calculate' returned a 'calculation_id', a hypothetical 'save_calculation' tool could accept it directly.
No pagination patterns for list-returning tools. 'calculate_stats' accepts a 'numbers' array but no guidance on max size, limits, or how LLM should batch large inputs. No 'limit' or 'offset' parameter to handle thousands of items without context explosion.