Loading ToolBench
Sample Spring Boot application demonstrating MCP client and server usage with WebFlux transport
Single tool 'executeSparkJob' has critical deficiencies. Description is 8 characters (Chinese: '启动spark任务'), far below the 20-char minimum and non-English, making it inaccessible to most LLMs. Input schema exists but parameter 'args' has only a 2-character description ('命令'). No output schema documented. Tool executes arbitrary shell commands via Runtime.exec() with no validation, sanitization, or error guidance, a severe security and reliability risk. No tool annotations (destructiveHint, idempotentHint) despite irreversible nature. Naming 'executeSparkJob' is acceptable but lacks verb clarity (execute is weak; 'submit_spark_job' or 'run_spark_job' would be stronger). No pagination, no structured output format, no recovery guidance on failure.
启动spark任务
Tool description is 8 characters in Chinese ('启动spark任务'), violating the 20-1024 character requirement and making it inaccessible to English-language LLMs. Parameter description is 2 characters ('命令'). Both must be replaced with clear English descriptions of 50-200 characters explaining WHAT the tool does, WHEN to use it, and what it returns.
No output schema documented. Tool returns a plain string ('Spark job executed successfully' or error message), but LLMs cannot plan downstream actions without knowing the response structure. Document a structured output schema with fields like {success: boolean, message: string, exit_code: number, error_details?: string}.
Tool accepts arbitrary shell commands via 'args' parameter with zero input validation or sanitization. Runtime.exec(args) is vulnerable to command injection. LLMs can be tricked into passing malicious payloads. Implement a whitelist of allowed Spark commands, validate arguments against a strict pattern, and reject anything outside the whitelist.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
Tool performs irreversible operations (submits Spark jobs) but has no error guidance, confirmation step, or dry-run mode. On failure, it returns raw error text from stderr without actionable recovery hints. Implement a confirmation pattern and return structured errors like {success: false, error_code: 'INVALID_ARGS', recovery_hint: 'Verify spark-submit is installed and cluster is accessible'}.
No tool annotations present. Tool is destructive (submits jobs) and irreversible, but lacks destructiveHint annotation. Add @Tool annotation with destructiveHint=true to signal to LLMs that this operation has side effects and should be used cautiously.