Loading ToolBench
Model Context Protocol server for controlling FiveM game client, including window management, input simulation, game launching, RCON commands, position tracking, and in-game notifications
Strong tool definitions with comprehensive descriptions and well-structured schemas. All 21 tools have clear, action-verb names and detailed descriptions (avg ~180 chars, within baseline 194). Input schemas are present and typed for all tools. Key strengths: excellent parameter descriptions with defaults, clear error recovery guidance (e.g., get_position auto-recovery), and domain-specific context (RCON, DevCon, mcp_bridge). Weaknesses: output schemas are not formally documented (only inferred from descriptions); no structured error response format; some tools lack explicit enum constraints (e.g., key names in key_down/key_up); no tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications.
Clicks a mouse button.
Brings the FiveM window to the foreground. Input tools do this automatically; call it explicitly to verify focus.
Reports the player's world position and heading as vec4(x, y, z, heading), plus interior and vehicle. Requires the mcp_bridge companion resource, which registers the client-side mcp_position command. If mcp_bridge is not running, this automatically runs "ensure mcp_bridge" over RCON and retries once before giving up - set FIVEM_RCON_PASSWORD for that recovery to work.
Reports whether the FiveM game window exists, its title, size, position, and whether it is focused.
Holds a key down. Pairs with key_up to release it. Keys are sent as hardware scan codes, not virtual keys, so GTA V's DirectInput/raw input reader sees them.
Releases a key that was held down by key_down.
Output schemas not formally documented. Tool descriptions infer return types (e.g., 'Reports the player's world position as vec4(x, y, z, heading)') but no structured schema is visible in code. LLMs cannot reliably parse unstructured text responses.
Key input tools (key_down, key_up, press_key) accept 'key' as free-form string with description listing examples ('A-Z, 0-9, F1-F24, enter, shift, space, left, up, right, down, etc.'). No enum constraint; LLMs may hallucinate invalid key names.
Tool annotations missing. All tools have clear risk classifications (READ_ONLY, WRITE, DESTRUCTIVE) in metadata but no readOnlyHint, destructiveHint, or idempotentHint in MCP schema. Agents cannot infer safety properties from tool definitions alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Launches the FiveM client, optionally connecting straight to a server address (host:port) via the fivem:// URI scheme. No-op if the client is already running.
Minimises the FiveM window so it stops covering the screen.
Moves the mouse cursor to an absolute screen position. Used for NUI/menu clicking, not camera control.
Moves the mouse cursor by a relative offset. This is what the in-game camera reads via raw input.
Shows a notification inside the game, so the player can see what the agent is doing. Goes over the client's devcon socket, so it needs no RCON password and no special permissions. Requires the mcp_bridge companion resource. With everyone: true (which does need RCON), a missing mcp_bridge is started automatically with "ensure mcp_bridge" and the broadcast is retried once. The single-client path has no reply to check, so a missing bridge there fails silently - use everyone: true or get_position first if you need to confirm the bridge is actually up. Supports GTA colour codes like ~g~ and ~b~.
Presses and releases a key in one call. Useful for single keypresses like Enter or Escape.
Closes the FiveM client. Asks the window to close cleanly by default; force terminates every FiveM process, which is what works when the game is hung.
Runs a command on the FiveM *server* over RCON, with no need to touch the game client or its console. Use for "restart <resource>", "refresh", "status", and companion-resource commands.
Reads the FiveM client console in real time, with attribution to the emitting channel (script:my_resource, etc.). This is strictly better than tailing the log because it preserves channel information. The tap is attached on demand and detaches after 60 seconds of inactivity to avoid race conditions in the client's console print-drain thread.
Reads the FiveM client log, which carries the same stream the F8 console renders: connection progress, resource loading, script prints, Lua errors and warnings. Pass the cursor from a previous call to get only what has been printed since. Supports regex filtering.
Hands the foreground back to whatever window had focus before a tool brought FiveM forward. Call this when finished driving the game so the user gets their own window back.
Captures the FiveM window as PNG bytes. Optionally crops to a window-relative region and/or downscales to fit a maximum width. Returns the PNG data plus the actual pixel dimensions delivered.
Captures several frames back to back, with minimal overhead between frames. Focusing and window measurement happen once up front; frames are encoded only after the loop. Useful for catching something that only appears for a few frames. Optionally runs a callback immediately after frame 0 is captured, from inside the loop - this is how you record the consequence of an action without waiting for a separate tool call.
Scrolls the mouse wheel.
Types literal text as Unicode key events. Suitable for the F8 console and chat boxes, which read characters through the normal Windows message loop. Newlines are sent as Enter keypresses.
Error handling returns plain text strings (e.g., 'RCON error: {ex.Message}', 'Error reading position: {ex.Message}'). No structured error classification (retryable vs. user-fixable vs. fatal) or recovery guidance. LLMs cannot distinguish transient failures from permanent ones.
Dependencies on companion resource (mcp_bridge) documented in descriptions but not enforced at tool level. get_position and notify silently fail or auto-recover without clear feedback. No pre-flight check tool to verify bridge status before multi-step operations.