Loading ToolBench
A Minecraft server ping monitoring system with support for both Java and Bedrock editions. Provides database storage of ping records and periodic polling of configured servers.
This server exposes 8 tools for managing Minecraft server configurations (Bedrock and Java). Tool naming and descriptions are adequate but generic. Schemas are present with proper types. However, the server has CRITICAL gaps: (1) No error handling documentation, operations like delete_bedrock_server have no guidance on what happens on failure; (2) Parameter descriptions are minimal, 'Hostname or IP address of the Bedrock server' is functional but not optimized for LLM reasoning; (3) No pagination support despite likely returning lists; (4) No tool output schemas documented, the response structure for get_bedrock_servers is inferred from the BedrockServer model but not explicitly declared in tool definitions; (5) No attempt to surface which tools are read-only vs. destructive via annotations (the metadata flags it, but tool definitions lack this); (6) Tool names are verb-noun but generic, 'update_bedrock_server' and 'update_java_server' duplicate pattern suggests missed opportunity for single parameterized tool or clearer distinction. The code is well-structured (abstract repository pattern, type hints, Pydantic models), but tool definitions for MCP consumption lack the rigor expected of production-grade agent tools.
Create a new Bedrock server entry in the database
Create a new Java server entry in the database
Delete a Bedrock server entry from the database
Delete a Java server entry from the database
Retrieve all configured Bedrock servers from the database
Retrieve all configured Java servers from the database
Update an existing Bedrock server entry in the database
No output schemas documented for any tool. get_bedrock_servers response structure is inferred from BedrockServer Pydantic model but never explicitly exposed as a tool output schema. LLMs cannot see what fields will be returned and cannot plan downstream chaining.
Destructive operations (delete_bedrock_server, delete_java_server) lack error handling guidance and recovery instructions. No mention of what happens on failure, whether the operation is idempotent, or how the agent should recover if the delete fails. Pattern requires 'Irreversible operations should support confirmation or dry-run'.
Tool descriptions are under 100 characters and lack LLM-optimized context. E.g., 'Retrieve all configured Bedrock servers from the database' (61 chars) does not explain when to use this vs. create, does not hint at pagination, and does not guide agent planning. Baseline for A-grade tools is 50-200 chars with discovery hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Update an existing Java server entry in the database
Parameter descriptions are minimal (15-40 chars). E.g., 'Name of the Bedrock server' does not hint at format constraints, length limits, or character restrictions. Rubric baseline is 50-100 chars per parameter with format guidance.
Duplicate tool patterns (get_bedrock_servers + get_java_servers, create_bedrock_server + create_java_server, update_bedrock_server + update_java_server, delete_bedrock_server + delete_java_server) suggest the agent must reason about which variant to call. This wastes LLM reasoning and invites mistakes. Consider a single parameterized set_server type: {"server_type": "bedrock|java", ...}.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). The Risk metadata provided in the spec flags are not propagated to MCP tool definitions. Destructive operations should be explicitly marked so agents and users can warn or require confirmation.
List operations (get_bedrock_servers, get_java_servers) do not support pagination (limit, offset, page_size). If the database grows, unbounded results will blow the context window. Baselines for A-grade tools include pagination with total count or next_cursor.
Port parameter has no min/max constraint documented. Valid Minecraft ports are 1-65535, but the schema only declares 'integer' with no bounds. Agents could pass port=0 or port=99999 and fail at runtime.