Loading ToolBench
Minecraft Forge modding environment setup and management tool
This MCP server is fundamentally non-functional as an agent tool interface. All 13 tools are shell script wrappers with minimal metadata. No input schemas are visible in the source code, tools only show shell invocations with generic '$@' argument passing. Descriptions are extremely terse (10-20 chars), providing almost no context for LLM tool selection. No parameter definitions, type constraints, or output schemas are documented. The server appears to be a Minecraft Forge development toolkit wrapped as an MCP interface, but the implementation completely fails to meet any production agent tool patterns. No transport mechanism is evident, the source shows only bash shell scripts, suggesting this may be a STDIO server at best, or not a functional MCP server at all.
Clean up resources by running Python cleanup script
Decompile Minecraft code by running Python decompile script
Get changed source files by running Python getchangedsrc script
Recompile Minecraft code by running Python recompile script
Reformat code by running Python reformat script
Reobfuscate code by running Python reobfuscate script
Reobfuscate code with SRG names by running Python reobfuscate script with --srgnames flag
Start the client by running Python runtime startup script
No input schemas visible for any tool. All tools invoke shell scripts with generic '$@' passthrough and no parameter definitions, types, or constraints.
Descriptions are critically short (5-20 characters) and uninformative. Examples: 'Start the server by running Python runtime startup script' (56 chars but generic), 'Clean up resources by running Python cleanup script' (50 chars). These fail to answer WHEN to use each tool, WHAT parameters it accepts, or WHAT it returns. Baseline for A+ tools: 50-200 chars with explicit purpose and usage guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Start the server by running Python runtime startup script
Update IDs by running Python updateids script
Update MCP by running Python updatemcp script
Update MD5 hashes by running Python updatemd5 script
Update names by running Python updatenames script
No parameter definitions visible anywhere in the source. Tools accept arbitrary arguments via shell '$@' but LLMs have no way to understand what parameters are valid, what their types are, what constraints apply, or what defaults exist. This violates the critical requirement that every parameter must have a description.
No output schemas documented. Tools are bare shell invocations with no indication of what they return, whether they return structured data or unstructured text, what fields are in the response, or what formats (JSON, plain text) to expect. LLMs cannot plan downstream tool calls or extract needed data.
No error handling or recovery guidance. Tools fail silently or with unstructured shell output. No distinction between retryable errors, user-fixable errors, and fatal failures. LLMs receive raw error codes or nothing and cannot self-correct or guide users.
Destructive operations (cleanup, recompile, reobfuscate, updateids, etc.) lack confirmation or dry-run support. Agents can accidentally destroy Minecraft source code with no safeguard. Pattern requires confirmation-request for irreversible operations.
Tool names lack semantic clarity. 'updateids', 'updatemd5', 'updatemcp' are vague, they don't convey what IDs, what MD5 hashes, or what MCP data is being updated. Better: 'update_source_file_ids', 'update_source_md5_hashes', 'update_mcp_mappings'. Current names force LLMs to guess the intent.
No evidence of MCP protocol implementation at all. Source code shows only bash shell scripts and a Java Minecraft Start class. No JSON-RPC, no tool registration, no message handling, no protocol negotiation. This suggests either: (1) the repository is not a functional MCP server, or (2) the MCP entry point is missing from the provided source.