Loading ToolBench
MCP server for Unity plugin management, AI reasoning, and document analysis
This server has 6 tools with significant definition quality gaps. Tool naming is inconsistent, some follow verb_noun (unity_help, unity_plugin_list) but others are vague or domain-specific (reasoning). Descriptions vary widely in quality: reasoning and unity tools have brief Chinese descriptions that lack actionable context for LLM selection. Input schemas are present for most tools but lack comprehensive parameter descriptions in the JSON Schema. Output schemas are undocumented, LLMs cannot infer what structure to expect. Error handling is basic (generic exception catches returning error strings). Parameters lack type constraints (e.g., version is a free-form string with no validation hints). The stream parameter on reasoning is non-standard (MCP tools should not expose streaming in input, streaming is a protocol-level feature). Overall, the server reads as a direct CLI wrapper rather than an agent-optimized interface.
推理工具。参数 prompt: 推理提示词。返回推理结果文本。
获取 OneTools Unity 支持的所有命令列表。自动区分 macOS/Windows 路径。无参数。返回命令帮助文本。
安装全局 Unity Package。参数 version: Unity 版本号。返回安装结果文本。
获取 Unity 项目已安装插件列表。无参数。返回插件列表文本。
获取 Unity 项目已安装插件列表（调试模式）。无参数。返回插件列表文本。
卸载全局 Unity Package。参数 version: Unity 版本号。返回卸载结果文本。
Descriptions are predominantly in Chinese and too brief (<50 chars for most); LLMs cannot determine when or why to select each tool.
No output schemas documented for any tool. LLMs cannot infer what structure to expect or plan downstream tool calls.
Parameter 'stream' on reasoning tool is non-standard for MCP; streaming should be handled at protocol level via Streamable HTTP, not exposed as a tool parameter. This breaks the abstraction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Parameter 'version' on unity_install_global_package and unity_uninstall_global_package lacks format/validation constraints (e.g., must be X.Y.Z?). LLMs will guess format and fail on invalid input.
Duplicate tools (unity_plugin_list vs unity_plugin_list_debug) confuse LLMs about which to use. Combines two concerns, split or unify with a mode parameter.
Destructive tool (unity_uninstall_global_package) lacks confirmation or dry-run pattern. No error guidance for recovery if uninstall fails.
Error handling is generic (catch-all exceptions returning free-form strings). LLMs cannot distinguish retryable vs fatal errors or know what to do next.
API key is stored in config.json and loaded at runtime (reasoning tool); no validation that it exists. Should use server-side secret injection via environment variables.