Loading ToolBench
An MCP server for Minecraft Java Edition with Fabric mod support, providing tools for building, terrain generation, block manipulation, and server management
This Minecraft Java Fabric MCP server defines 12 tools with functional names and descriptions, but exhibits significant quality gaps. Tools are named with action verbs (server_get_status, advancement_grant, command_execute) which is good. However, descriptions are inconsistent in depth and comprehensiveness. Many parameters lack type information in visible schemas, and output schemas are entirely undocumented. The tools span read-only operations (safe) to destructive operations (reload_resources), but error recovery guidance is minimal. Security-sensitive operations like command_execute accept raw, unsanitized input. The test suite (tools/itest/cases/*.py) provides some behavioral documentation but does not substitute for proper parameter schemas and output documentation. Average tool score: 58/100.
Get the JSON definition for a specific advancement (read-only)
Grant an advancement to a player (global operation - mutates persistent player state)
List all advancements in the registry with pagination support (read-only registry listing)
List advancements earned by a specific player
Revoke an advancement from a player (global operation - mutates persistent player state)
Execute a raw Minecraft slash command on the server
Output schemas are entirely undocumented. Tool definitions do not specify what fields or structure LLMs should expect from responses. This forces agents to guess at response structure and breaks tool chaining (e.g., after listing advancements, the LLM cannot know which field contains the advancement_id for a subsequent grant call).
command_execute accepts raw, unsanitized Minecraft slash commands with minimal validation or permission checking. No description of what commands are allowed, blocked, or dangerous. No error guidance for command failures. Agents could execute destructive commands unintentionally.
Parameter schemas lack comprehensive type information. For example, 'mode' in advancement_grant and advancement_revoke is described as a string ('e.g. only') with no enum constraint or validation. LLMs will guess valid mode values, leading to failed calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
List currently connected players
Get the server's MOTD (Message of the Day) as a plain string (read-only)
Get server status including Minecraft version and online player count (read-only introspection)
Reload server resources and datapacks (equivalent to /reload command - session-affecting, destructive operation)
Flush every loaded world to disk (safe, idempotent, non-destructive)
Set the server's MOTD (Message of the Day) text - global operation that modifies persistent server state
Destructive operations (server_reload_resources) lack confirmation or dry-run mechanisms. A tool that reloads datapacks (session-affecting, cannot be cleanly undone) should require explicit user confirmation or offer a dry-run mode before executing.
Error handling is minimal. Test code shows tolerant error checking (e.g., 'error' not in text.lower()), but actual error responses to the LLM are not documented. No guidance for retryable vs. fatal errors, no suggestions for recovery (e.g., 'try search_advancements if advancement_id is unknown').
Parameter descriptions are vague or generic. Example: 'UUID of the player' for player_uuid, acceptable, but does not explain the UUID format (standard hyphenated UUID, no hyphens, or Minecraft offline UUID). 'The new MOTD text to set' for motd, no character limits, encoding constraints, or special character handling documented.
Pagination parameters (limit, offset in advancement_list_all) lack bounds constraints. No documentation of min/max values, default, or maximum allowed limit. Unbounded limit lets LLMs request thousands of advancements, potentially exhausting token budget or overwhelming the server.
Tool composition breaks at advancement discovery. advancement_list_all returns advancements with pagination (limit, offset) but the response schema is not documented. After listing, the LLM cannot know if the response contains 'id' or 'advancement_id', making it unable to pass the result to advancement_get_definition or advancement_grant without guessing.