Loading ToolBench
MCP server for Minecraft — RCON commands, log monitoring, database queries, and plugin health checks
This server has 4 tools with basic but incomplete definitions. Tool names are verb-based and clear (execute_command, read_latest_logs, read_filtered_logs, query_database), following naming conventions. However, descriptions are minimal (20-45 chars), parameters lack detailed constraints, and output schemas are undocumented. The code shows proper input parameter schemas with types and descriptions at the JSON Schema level, but descriptions are too generic to guide LLM tool selection effectively. No error handling guidance is present. The server's reliance on STDIO transport and lack of advanced features (tool annotations, error recovery patterns, idempotency hints) further limits production readiness.
Execute a Minecraft RCON command on the server
Execute a read-only SELECT query against the SQLite database
Read filtered log entries matching a prefix, optionally filtered by event type
Read the last N lines from the Minecraft server log
Tool descriptions are 20-45 characters, below the 50-200 char baseline for LLM-optimized descriptions. 'Execute a Minecraft RCON command on the server' (45 chars) lacks context for when/why to use this tool vs alternatives, and does not document that this is a write operation or that commands are irreversible. 'Query a read-only SELECT query against the SQLite database' (60 chars) is clearer but still lacks prerequisites and failure modes.
No output schema documentation. Tools return responses but no structured schema is documented in the code. LLMs cannot infer what fields to extract or plan downstream calls without explicit output type definitions. Pattern requires: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
execute_command has no input validation or constraints. 'command' parameter accepts any string with zero guidance on valid RCON commands, syntax, or dangerous patterns. LLM could pass malformed or injection-payload commands. Missing: length limits, command prefix constraints, or validation examples.
No error handling guidance. Code includes error messages (e.g., 'Error: Log file not found', RCON connection failures) but these are raw strings without recovery guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next: 'Log file not found. Check SERVER_DIR configuration and restart the server.'
query_database accepts freeform SQL with only a comment claiming 'write operations are forbidden'. No actual validation prevents DELETE, DROP, UPDATE, or INSERT. Malicious agents or prompt-injection could execute destructive queries. Per pattern:secret-injection and pattern:tool-gateway, all agent input must be sanitized. Implement SQL parsing to reject non-SELECT statements.
No permission gates or audit trails. execute_command can invoke any RCON command (ban, stop server, op players) without permission checks or logging who called what. Per pattern:audit-trail and pattern:permission-gate, destructive tools must verify agent authority and log all calls for compliance.
Parameter descriptions are missing or minimal. 'lines' in read_latest_logs has description 'Number of recent log lines to read (default: 50)' (55 chars) but lacks range constraints (min/max). 'since_position' in read_filtered_logs says 'Byte offset to start reading from (for incremental reads)' but does not specify how to obtain valid positions or what happens if position exceeds file size. Per pattern, descriptions must include format, range, and constraints.
No pagination or result limits. read_latest_logs accepts arbitrary 'lines' count with no upper bound. An LLM could request 1,000,000 lines, exhausting memory. Per pattern:paginated-result and mxe:enforce-result-limits, tools returning lists must cap results and enforce pagination.
Tool composition lacks idempotency guarantees. execute_command is not marked idempotent and can trigger side effects (commands like 'op player_name' succeed on first call, then silently fail if player is already opped). Per pattern:idempotent-operation, tools with side effects should document their idempotency and provide retry semantics.