Loading ToolBench
MCP server for AI agents controlling Minecraft bots using mineflayer
This MCP server defines 5 tools for Minecraft bot control via mineflayer. Tool definitions are present with descriptions and input schemas, but have significant gaps. Naming follows verb_noun convention well (mc_status, mc_connect, mc_chat, mc_reconnect, mc_execute). Descriptions exist but are inconsistent in quality and actionability. Input schemas are partially defined, mc_status and mc_reconnect have empty objects (no parameters), while mc_connect and mc_chat have typed parameters with descriptions. mc_execute has parameters with timeout but lacks bounds or validation guidance. No output schemas are documented anywhere in the provided source. Error handling is minimal, no recovery guidance, categorization, or actionable error messages visible. The most critical issue: mc_execute accepts arbitrary JavaScript code with a timeout parameter, representing an IRREVERSIBLE risk with minimal guardrails. Security: no evidence of secret injection patterns, permission gating, or audit logging. Composition is reasonable (each tool is single-purpose), but output structure is not documented, forcing LLMs to infer response formats.
Send a chat message to the Minecraft server
Connect a bot to a Minecraft server at specified host/port with username
Execute arbitrary mineflayer JavaScript code with access to bot object for direct control and automation
Reconnect the bot to the Minecraft server if connection was lost
Get comprehensive bot status including position, health, food, inventory (tools/food/materials), nearby entities, threats (hostile mobs), nearby resources, infrastructure (crafting table/furnace/chests), biome, time of day, and actionable warnings for survival threats
No output schemas documented for any tool. LLMs cannot parse responses or chain tools together without knowing the response structure. Source code shows mc_status returns Promise<string>, but actual JSON/object structure is undocumented.
mc_execute accepts arbitrary JavaScript code with minimal guardrails. No confirmation pattern, no dry-run, no sandboxing, no audit logging. Marked IRREVERSIBLE but lacks error classification (retryable vs. fatal), timeout bounds, or recovery guidance. LLM could execute destructive code without warning.
Parameter bounds and constraints are missing or underspecified. mc_connect: no port range (should be 1 - 65535). mc_chat: no message length limit. mc_execute: no timeout bounds, no code length limit. These missing constraints invite hallucinated invalid values from LLMs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling is absent. No error classification (retryable vs. user-fixable vs. fatal), no recovery guidance, no invalid-value feedback. Example: if mc_chat fails due to character filter, the LLM has no guidance on what to do next.
Tool descriptions lack context about when to call them and prerequisites. mc_connect: no mention that this must be called once per bot. mc_reconnect: no guidance on when/why to use it vs. mc_connect. mc_execute: no mention of available APIs or security constraints.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot infer which tools are safe to retry, which modify state, or which are read-only. This is especially critical for mc_execute (marked IRREVERSIBLE).
No permission gating or audit logging visible. mc_execute could be called by any agent without authorization checks. No trace of who called what tool, when, or with which parameters, required for compliance and incident response.