Loading ToolBench
MCP server for BlockOrchestra, a Minecraft mod that enables scripting and automation via JavaScript. Provides tools for script execution, world interaction, inventory management, recipe queries, and persistent key-value storage.
BlockOrchestra MCP has 19 tools with basic descriptions and schemas, but significant quality gaps limit production readiness. Tool names follow verb_noun convention (script/eval, recipe/get, store/set), which is good. However, descriptions are inconsistent: some are clear (script/eval: 'Execute JS synchronously'), others are vague or incomplete (health: 'Report engine health', no detail on what metrics). Parameter descriptions are minimal; many use placeholder text like 'ignored' for dummy parameters. Input schemas are present but sparse, most tools have only 1-2 parameters with basic type info, no enums, ranges, or validation hints. Output schemas are entirely undocumented; LLMs cannot predict what fields to expect from recipe/query or store/list. Error handling is absent from descriptions, no guidance on retryability, failure modes, or recovery steps. Security concerns: script/eval and script/evalAsync execute arbitrary JavaScript, a severe risk that is not flagged in descriptions or error handling. No mention of sandboxing, timeout limits, or input validation. Overall, the server is functional but lacks the polish and safety documentation expected of production tools.
List the available API documentation pages.
Read an API documentation page (e.g. 'container', 'book', 'input').
Report engine health.
Disable player input for this connection (blocks accidental mouse/keyboard).
Re-enable player input for this connection.
Get one recipe by id (e.g. 'minecraft:ladder') as a normalized JSON object (result, ingredients, pattern...).
Query recipes: filter by result item id, ingredient item id, and/or recipe type/serializer. Returns {total, recipes}.
Arbitrary JavaScript execution (script/eval, script/evalAsync) lacks security documentation. No mention of sandboxing, timeout limits, input validation, or error recovery. Critical for production safety.
Output schemas completely undocumented. LLMs cannot predict response structure for recipe/query, store/list, health, docs/list, or recipe/types. Breaks downstream tool chaining and forces agents to guess field names.
Dummy parameters with 'ignored' descriptions (script/status, script/abort, health, input/disable, input/enable, docs/list, recipe/types, store/list, test/announce). These should be removed or replaced with meaningful parameters. Wastes tokens and confuses LLMs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
List all recipe types with their recipe counts (sorted by count desc).
Abort the running script.
Execute JS synchronously and return the result.
Submit a JS script without waiting.
Check whether a script is running.
Wait up to N seconds (default 20) for the running script to finish; returns as soon as it finishes.
Delete a key from the persistent script KV store.
Read a value from the persistent script KV store (bo/kv.json).
List all keys in the persistent script KV store (sorted).
Write a value into the persistent script KV store (bo/kv.json); key and value are strings.
Show a line in the local chat area without sending a chat message to the server (used by the test runner to describe the current task).
Sleep the MCP thread for N seconds.
No error handling guidance in any tool description. LLMs cannot determine if failures are retryable, user-fixable, or fatal. No recovery hints (e.g., 'If recipe not found, try recipe/query').
recipe/query accepts optional filters but no documentation of mutual exclusivity, default behavior, or result ordering. No mention of pagination limits or total count in response.