Loading ToolBench
MCP server for controlling a game character with movement, missile firing, and vision/enemy detection capabilities
This MCP server exposes 4 game control tools with significant quality gaps. Tool names lack clear action verbs and follow unconventional naming patterns (game-charactor-move-operation, fire-missile, vision, vision-relative). Descriptions exist but are minimal and in Japanese, providing limited context for LLM tool selection. Input schemas are present but sparse, parameters lack detailed descriptions explaining constraints, formats, or ranges. Most critically, no output schemas are documented, forcing LLMs to infer response structure. Error handling is absent, no recovery guidance or error categorization visible in the definitions. The server implements basic game mechanics but does not follow production-grade tool definition standards.
ゲームキャラクターからミサイルを発射する
ゲームキャラクターを操作する
ゲームキャラクターの視界情報。どの方向に敵がいるかなどを知る
ゲームキャラクターの視界情報（相対座標）。プレイヤーからの相対的な敵の位置情報を取得する
Tool names lack action verbs and follow non-standard conventions. 'game-charactor-move-operation' should be 'move_character'; 'vision' and 'vision-relative' are ambiguous discovery names. Hyphenated names with 'operation' suffix do not follow verb_noun pattern.
Descriptions are minimal (10-30 chars), in Japanese, and lack context for LLM tool selection. Missing WHAT the tool does, WHEN to use it, and prerequisites. 'ゲームキャラクターを操作する' (Move game character) provides no guidance on coordinate ranges, coordinate system semantics, or absolute vs. relative positioning.
Input parameters lack descriptions. 'x' and 'z' coordinate parameters have minimal annotations; no explanation of coordinate system semantics, valid ranges, or constraints. 'r' in fire-missile states degree format but lacks detail on behavior at boundary angles or post-360° wrapping.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 27 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
No output schemas documented. Tools return JSON from Express endpoints (e.g. /api/vision returns playerPosition + visionInfo array with relativeX, relativeZ, distance, direction fields), but response structure is not declared in tool definitions. LLMs cannot plan downstream use without knowing what fields to expect.
No error handling or recovery guidance. Tool definitions lack error responses, validation rules, or actionable error messages. The Express server may return HTTP 400/500, but MCP tool definitions do not expose error contract or recovery steps.
Parameter validation not declared. fire-missile 'r' parameter accepts 0-360 degrees but no enum or range constraint visible; game-charactor-move-operation x, z have no documented limits. LLMs will not self-validate and may pass out-of-bounds values.
vision and vision-relative take no input parameters but their distinct purposes are not clear from names alone. Users cannot infer the difference without extensive description. Names should clarify: get_absolute_vision vs get_relative_vision, or similar.