Loading ToolBench
An MCP server that exposes Cheat Engine functionality via HTTP API, enabling remote process manipulation, memory access, debugging, code injection, and system analysis through a standardized interface.
This server exposes 39 tools with significant quality gaps. All tools have descriptions (positive), but most are extremely brief (10-30 chars), well below the 50-200 char LLM-optimized baseline. Parameter descriptions exist but are minimal and lack constraints (enums, ranges, formats). No output schemas are documented anywhere in the codebase. Critical security issue: tools like `run_command`, `shell_execute`, `inject_dll`, `execute_code` accept arbitrary user input with no validation guidance, sanitization hints, or error recovery patterns. Tool naming is generally acceptable (verb_noun pattern), but composition is poor, `execute_code` and `execute_code_ex` are near-duplicates; `key_down`/`key_up`/`do_key_press` should be consolidated. No idempotency guarantees, no pagination for list tools, no error classification (retryable vs fatal). The server is a thin HTTP wrapper around Cheat Engine's Lua API with minimal agent-facing design.
Allocate memory in the target process
Analyze a function to find calls and basic structure
Assemble a single instruction into machine code
Execute Cheat Engine auto-assemble script
Validate an auto-assemble script without executing it
Remove all active breakpoints
Attach debugger to the current process
Delete a file
Disassemble instructions at a given address
No output schemas documented. Tools return JSON but LLMs cannot predict field names, types, or structure. Breaks downstream tool chaining and forces agents to guess response format.
Descriptions are too brief (10-30 chars, well below 50-200 char baseline). LLMs cannot determine when to select tools or what they return. E.g., 'Set an execution breakpoint at a given address' lacks context on breakpoint behavior, side effects, or when to use vs set_data_breakpoint.
No input validation or constraint documentation. Parameters like 'command' in run_command and 'script' in auto_assemble accept arbitrary strings with no sanitization hints, injection warnings, or error recovery guidance. Critical for security-sensitive tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Simulate a complete key press (down and up)
Execute code at a given address in the target process
Execute code with extended options
Check if a file exists
Find the start and end addresses of a function containing a given address
Free allocated memory in the target process
Get recorded hits for a breakpoint
List subdirectories in a directory
List files in a directory
Get version information from a file
Get detailed information about an instruction at a given address
Get current mouse position
Get the color of a pixel at screen coordinates
Get screen dimensions and DPI information
Get the system temporary folder path
Inject a DLL into the target process
Inject and execute a .NET DLL in the target process
Check if a key is currently pressed
Simulate key press down
Simulate key release
List all active breakpoints
CE HTTP Bridge Active
Read text from the system clipboard
Remove a breakpoint at a given address
Run a shell command and capture output
Set an execution breakpoint at a given address
Set a data access breakpoint at a given address
Set mouse position
Execute a shell command asynchronously
Write text to the system clipboard
Duplicate/overlapping tools reduce clarity. execute_code and execute_code_ex differ only in parameter style; key_down/key_up/do_key_press should be one composite tool. LLMs waste reasoning cycles choosing between near-identical options.
No error classification or recovery guidance. Tools return success/error but do not indicate if errors are retryable, user-fixable, or fatal. Agents cannot plan recovery or know when to ask the user.