Loading ToolBench
MCP server exposing Minecraft 1.8.9 client capabilities including Baritone pathfinding, module control, player queries, and world interaction through a JSON-RPC interface
This Minecraft client MCP server has well-structured tool names (verb_noun pattern: baritone_goto, baritone_mine, baritone_stop) and clear, domain-specific descriptions (avg ~120 chars). However, critical gaps undermine production readiness: (1) Input schemas are present but lack enum constraints for block types and player names, inviting hallucinated values. (2) No output schemas documented, callers cannot plan downstream actions or extract structured data. (3) No error handling guidance, tools return success/failure with no recovery hints. (4) Transport mechanism unknown, cannot assess remote accessibility. (5) Zero protocol features implemented (no logging, sampling, cancellation, progress, error reporting, tool annotations). The 9 tools are well-named and described relative to community baselines, but lack the rigor expected of production agent tools.
Query what Baritone has done recently: blocks mined, blocks placed, entities killed, and the player's current position. Useful for verifying task completion.
Follow another player. Provide "player": "name". Baritone will continuously pathfind to keep them in view. Call baritone_stop to end following.
Walk/pathfind to coordinates or to another player using Baritone. Give x/z (y optional -- omit y for same-level travel), or "player": "name". Optional "range" stops within N blocks of the goal instead of exactly on it. Normal movement only. Baritone avoids hazards it is told about (see baritone_set_avoid_blocks: e.g. cobweb, water).
Mine blocks of a given type within a radius. Baritone will pathfind to them and break them. Provide "block" (e.g. "stone", "diamond_ore") and optional "radius" (default 32, max 64). Returns the count of blocks targeted.
Tell Baritone to avoid breaking certain block types (e.g. 'cobweb', 'water'). Provide a list of block names. Baritone will treat these as hazards and path around them.
Tell Baritone which blocks are safe to discard (e.g. 'dirt', 'cobblestone'). These will be dropped if inventory is full during mining.
No output schemas documented for any tool. baritone_status and baritone_activity return unspecified structures, preventing LLMs from planning downstream actions or extracting required fields (e.g., current_position, eta, blocks_mined).
Block type parameters (baritone_mine, baritone_set_avoid_blocks, baritone_set_throwaway_blocks) accept free-form strings with no enum constraint. LLMs will hallucinate invalid block names like 'diamond_block_ore' or 'stone_brick_slab' instead of canonical Minecraft names.
No error handling guidance. Tools provide no recovery hints (e.g., 'Player not found. Available players: [list]' or 'Pathfinding blocked by terrain. Try baritone_set_avoid_blocks to mark hazards'). Agents cannot self-correct on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Like baritone_goto but with autosprint enabled. Sprinting consumes hunger but is faster. Give x/z (y optional), or "player": "name". Optional "range" stops within N blocks instead of exactly on it.
Query Baritone's current state: whether it is pathing, the current goal, ETA, and the player's position.
Stop all Baritone pathfinding and goal-seeking immediately.
Transport mechanism unknown. Build output shows Java/Gradle but no MCP server bootstrap code visible. Cannot verify HTTP, SSE, or STDIO transport, hard cap at 40 for protocol readiness.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read-only queries (baritone_status, baritone_activity) from state-modifying operations (baritone_goto, baritone_mine) without explicit hints.