Loading ToolBench
An MCP server for generating, compiling, and fixing Rust Cargo projects with LLM assistance and vector database support
The RustCoder MCP server defines 3 tools with basic descriptions and some schema information, but falls short of production quality across multiple dimensions. All three tools have descriptions present, but they are verbose, contain example output rather than concise guidance, and lack clarity on parameter constraints. The `generate` tool has a critical typo ('requiremenets' instead of 'requirements'). Parameter descriptions are present but generic. No output schemas are documented. Error handling is minimal, tools return generic error strings without guidance on recovery. The tools themselves violate the single-responsibility principle: `compile_and_fix` performs two distinct operations (compile and fix), suggesting it should be split. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The server is STDIO-only, which caps its protocol readiness score at 50 and severely limits practical deployability.
Compile a Rust cargo project and return the compiler output. The argument `code` is a text string that contains all files in the project. Each file is seperated by a [filename: path_to_file] line. The return value is a text string that contains the Rust compiler output.
Compile a Rust cargo project and fix any compiler errors. The argument `code` is a text string that contains all files in the project. Each file is seperated by a [filename: path_to_file] line. The return value is also a text string that contains all files in the project in the same format as the input `code` argument.
Generate a new Rust cargo project from the description and requirements. The input arguments are * description: a text string description of the generated Rust project. * requiremenets: functional requirements on what the generated Rust project. The return value is a text string that contains all files in the project. Each file is seperated by a [filename: path_to_file] line.
Tool 'compile_and_fix' violates single-responsibility principle by combining compile + fix into one tool. LLMs cannot distinguish when to use this vs the standalone 'compile' tool, and the bundled operation prevents fine-grained control.
Parameter descriptions are generic and lack actionable constraints. E.g., 'requirements' described as 'functional requirements on what the generated Rust project' (incomplete sentence). Parameters should specify format, range, or enum values, e.g., 'functional requirements as a comma-separated list of 1-5 features (e.g., "CLI argument parsing, error handling")'.
No output schemas documented. Tool descriptions include inline example outputs (Cargo.toml + src/main.rs), but there is no formal schema declaring the structure of returned strings (e.g., does 'combined_text' always follow '[filename: ...]' format?). LLMs must infer structure from examples, increasing parsing errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. 'generate' and 'compile_and_fix' create/modify files (write side effects), while 'compile' is read-only. LLMs cannot infer from names alone whether a tool is safe to retry, making them cautious about multi-attempt recovery strategies.
Error handling is minimal. All three tools catch httpx exceptions and return generic strings like 'Error trying to generate a Rust project: ...' or 'Rust compiler error.' No recovery guidance, no error classification (retryable vs fatal), and no suggestions for next steps. LLMs cannot determine if they should retry, adjust inputs, or escalate.
Typo in 'generate' tool parameter description: 'requiremenets' should be 'requirements'. This appears in both the docstring and parameter name, risking API contract mismatches.
Tool descriptions include large example output blocks (Cargo.toml + Rust code examples). These examples teach the FORMAT but waste tokens and risk LLMs reusing literal example values (e.g., 'a_command_line_calcu' as a project name). Use formal output schema instead.
'max_attempts' parameter in 'compile_and_fix' has no min/max bounds or validation. An LLM could pass max_attempts=1000000, causing runaway loops or resource exhaustion. Specify 1 - 10 range in parameter description and validate server-side.
No pagination or result-size limits documented. 'compile' returns full compiler output as a single string, a large project with verbose errors could produce multi-MB output, exhausting context windows. Consider returning structured error summary + option to fetch full output.