Loading ToolBench
MCP server for Cyberpunk 2077 modding tools, providing offline file-based tools (import/export, modding utilities) and live in-game tools via CETBridge
WkMCP defines 13 tools with consistent naming (verb_noun pattern: live_*, inspect_*) and detailed descriptions (avg ~180 chars, well above 10-char minimum). However, critical gaps undermine quality: NO input schemas are visible in the provided source code, only parameter names and descriptions appear in the tool list. Parameter descriptions are present and specific (e.g., 'Lua code to run', 'Root folder of Cyberpunk 2077 installation'), but without JSON Schema type definitions, LLMs cannot validate inputs or understand constraints. Output schemas are entirely undocumented, no tool declares what fields it returns. Error handling is absent from descriptions; tools like live_execute_lua note they 'can freeze the game' but offer no recovery guidance. The test file shows input validation (e.g., file extension checks, missing path rejection) but this logic is not reflected in tool descriptions, leaving agents unaware of constraints.
Summary of a quest phase graph (.questphase / questQuestPhaseResource): its nodes (with a per-type histogram), the node→node edges reconstructed from the socket connections, the entry/exit nodes (questInput/questOutput), and the .scene files and sub-phases it triggers. The map of a quest's flow — which scenes fire, in what order, and where it starts/ends — without hand-walking the handle graph. Pair with inspect_scene on the referenced .scene files. Accepts a .questphase or its .json.
Active status effects on the player: ID, remaining duration, number of stacks.
Current visual appearance of the player (or a scanned NPC): appearance name + customization.
Runs several Lua statements in a row in a single round trip (more efficient than N live_execute_lua calls). Each statement is independent: the failure of one does not interrupt the others.
Currently equipped items: weapons by slot, clothing, cyberware, quickslots.
No input schemas visible in source code. All 13 tools lack JSON Schema type definitions, constraints (min/max, enums), and format declarations. LLMs cannot validate inputs or understand parameter constraints.
Output schemas completely undocumented. No tool declares what fields it returns, data types, or structure. Agents cannot plan downstream calls or extract required data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | 2026-07-28+ | v2 |
Evaluates a Lua EXPRESSION in the live game and returns its serialized value (CET types handled: CName, TweakDBID, Vector4, Quaternion). E.g.: "Game.GetPlayer():GetLevel()". To run statements without a return value, use live_execute_lua.
Runs Lua code in the CET console of the live game (loadstring + pcall). For side effects (spawn, state modification…). The output of print() is captured and returned. To READ a value, prefer live_eval. ⚠ Can freeze the game (infinite loop): a server-side timeout protects the agent, not the game.
Game state: in-game time, scene tier (gameplay/menu/cinematic), weather, zone type.
Lists the player's inventory (name, quantity, TweakDBID, quality). Optional filter by type (Weapon, Clothing, Consumable, Gadget, Cyberware, Mod, Crafting, Quest, Junk).
Scans entities near the player within a radius: name, type, distance, position. Optional filter by type (NPC, Vehicle, Item, Device).
In-game player state: level, street cred, health, position. Requires the player spawned.
Checks the connectivity of the in-game bridge (CETBridge mod). Indicates whether the bridge is connected, through which transport (tcp/file), the listening port, the age of the last heartbeat and the mod folder. Works even with the game off (diagnostic). To call first before any other live_* tool.
Lists the vehicles owned by the player (garage): names + TweakDBID.
No error handling guidance in tool descriptions. live_execute_lua warns it 'can freeze the game' but offers no recovery path. Tests show input validation (file extension, missing path) but descriptions do not expose these constraints to LLMs.
Parameter descriptions lack format/constraint details. 'maxNodes' and 'maxEdges' have no min/max bounds stated. 'radius' in live_nearby_entities has no unit clarification (meters assumed but not explicit). 'type' filters lack enum values.
gamePath parameter is optional but its fallback behavior (CET_BRIDGE_DIR env var) is not documented in descriptions. Agents cannot predict when the parameter is required vs optional.