Cheat Engine MCP Bridge: Driving Cheat Engine From an AI Agent Over a Named Pipe
Connect Cursor, Copilot & Claude AI directly to Cheat Engine via MCP. Automate reverse engineering, pointer scanning, and memory analysis using natural language.
At a glance
- What is it?
- The project puts an MCP server in front of Cheat Engine's Lua API, so Cursor, Copilot or Claude can issue memory reads, pointer chain walks and breakpoints as tool calls. It is a Windows-first bridge with a TCP escape hatch, and the interesting part is where the trust boundary sits.
- Who is it for?
- Adopt it if you already work inside Cheat Engine on Windows and want an agent to drive the same API you would call by hand; the named pipe path needs no extra daemon and the Lua bridge loads with a single dofile.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly Lua, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The manual loop this replaces, and who is stuck in it
Cheat Engine is a GUI tool. Its Lua engine is scriptable, but the normal workflow is still a person clicking through a memory viewer, setting a write breakpoint, watching the instruction that fires, and writing the address down. For a single value that is fine. For a pointer chain that survives a game update, or for mapping a packet handler in a binary you have never seen, the loop is long: find the address, find what writes it, find what writes that, repeat. The README frames the cost as days or weeks of manual work against gigabytes of memory and millions of addresses.
The bridge targets people who already know what they want to ask. Its own examples are the giveaway: find the packet decryptor hook, find the opcode behind character coordinates, find a unique AOB pattern so a trainer survives a patch. Those are questions a reverse engineer asks out loud. The project's answer is to let an AI agent ask them through Cheat Engine's own API instead of a human doing it by hand. It is not a beginner's tool, and it does not pretend to be: the setup assumes you can load a Lua script into Cheat Engine and edit an MCP client config.
Two processes, one named pipe, and a worker thread inside Cheat Engine
The architecture diagram in the README is the clearest part of the documentation. An AI agent (Claude, Cursor, Copilot) talks JSON-RPC over stdio to mcp_cheatengine.py, a Python MCP server. That server talks over a Windows named pipe, \\.\pipe\CE_MCP_Bridge_v99, to a Lua script running inside Cheat Engine. The Lua side splits into a worker thread that does blocking I/O and a main thread that owns the GUI and the CE API; the two synchronise, and only the main thread touches the target process.
That split matters more than it looks. Cheat Engine's API is not thread-safe in the general case, so pushing pipe reads onto a worker and marshalling API calls back to the main thread is the standard way to keep the GUI responsive while an agent is mid-scan. The cost is latency: every tool call crosses stdio, then a pipe, then a thread hop, then the CE API. For a read_integer that is invisible. For a scan_all over a large region it is not, and the README gives no timing figures, so treat throughput as unmeasured.
The transport is the sharp edge. The pipe is Windows only because it relies on pywin32. When the MCP server cannot run on the same Windows host as Cheat Engine, the project offers a TCP relay: ce_tcp_relay.py runs on Windows next to Cheat Engine, and the MCP server connects to it with CE_MCP_TRANSPORT=tcp. Cheat Engine still runs on Windows; only the Python side moves. The README is explicit that anyone who can reach the relay can control the bridge, which is the correct way to state it and worth repeating: the relay is an unauthenticated remote control for a debugger.
Getting it running: pip, dofile, and one JSON block
Installation is two commands. pip install -r MCP_Server/requirements.txt, or manually pip install mcp pywin32. Python 3.10 or newer is the stated floor.
On the Cheat Engine side you enable DBVM if you plan to use the DBVM tools, then load the bridge. The preferred path is File then Execute Script, opening MCP_Server/ce_mcp_bridge.lua and executing it. If your build does not show that menu item, the README gives the fallback: Table then Show Cheat Table Lua Script, paste dofile([[C:\path\to\cheatengine-mcp-bridge\MCP_Server\ce_mcp_bridge.lua]]) and execute. Success looks like the line [MCP v12.0.0] MCP Server Listening on: CE_MCP_Bridge_v99.
On the client side you add a server block to your MCP config: command python, args pointing at MCP_Server/mcp_cheatengine.py, then restart the IDE. For Codex the README shows a TOML block under [mcp_servers.cheatengine] and notes that the Windows path should use single quotes so TOML treats backslashes literally. Verification is a ping tool call that returns {"success": true, "version": "12.0.0", "message": "CE MCP Bridge Active"}.
The TCP path adds three steps: start the relay with python C:\path\to\...\MCP_Server\ce_tcp_relay.py --host 127.0.0.1 --port 9876, install the MCP dependency without pywin32 via pip install -r MCP_Server/requirements-tcp.txt, and set CE_MCP_TRANSPORT, CE_MCP_HOST and CE_MCP_PORT in the environment or the client's env block. The README notes this also works under WSL without changing the Lua bridge, which is the practical reason the relay exists.
What the agent can actually call
The README advertises roughly 180 MCP tools and groups a subset into tables. Memory tools include read_memory, read_integer, read_string, read_pointer_chain for paths like [[base+0x10]+0x20], scan_all and aob_scan. Analysis tools include disassemble, analyze_function, dissect_structure, get_rtti_classname for C++ object identification, find_references and find_call_references. Debugging tools include set_breakpoint and set_data_breakpoint, described as hardware breakpoints, plus a start_d... entry that the excerpt cuts off mid-word.
That truncation is worth naming rather than guessing around. The supplied README ends inside the debugging table, so the full tool inventory, the DBVM-specific tools, and any write or injection tools are not visible here. The claim of roughly 180 tools is the project's own; this article cannot confirm the count or the shape of the remainder. If your workflow depends on a specific capability, the honest move is to read the tool registrations in mcp_cheatengine.py and the handlers in ce_mcp_bridge.lua before assuming it exists.
The design choice behind the tool list is also worth flagging. These are thin wrappers over Cheat Engine primitives, not high-level workflows. read_pointer_chain resolves a chain you already know; it does not discover one. find_references finds cross-references; it does not tell you which one matters. The intelligence is meant to live in the model, and the bridge's job is to make the primitives cheap to call. That is a defensible split, but it means the quality of your result tracks the quality of your prompts and the model's grasp of x86 and game internals, not the bridge.
The trust boundary is the whole security story
An MCP server that exposes set_data_breakpoint and arbitrary memory reads to a language model is a remote code execution surface with extra steps. The README does not claim otherwise, and it does say the relay should stay bound to trusted interfaces because anyone who can reach it can control the Cheat Engine bridge. There is no authentication mentioned on the pipe or the relay, no allowlist of tools, and no confirmation step described between an agent's request and a breakpoint being set in a live process.
The named pipe is the safer default because it is local and Windows ACLs apply. The TCP relay removes that protection by design. If you run CE_MCP_HOST against anything other than loopback, you have built an unauthenticated debugger endpoint, and the README's own warning is the only control it offers. For CTF work on a disposable VM that is a reasonable trade. For a shared workstation or a corporate network it is not, and nothing in the material suggests the project intends it to be.
A second, quieter failure mode: pointer chains and AOB signatures go stale. The README sells AOB scanning as the fix for post-update breakage, which is true only if the pattern you generate is genuinely unique and stable across builds. The bridge can produce a signature; it cannot tell you whether that signature will still match after the developer recompiles. That verification remains manual, and the README does not describe a step for it.
Where it sits next to Frida and a plain Cheat Engine table
The obvious alternative for scripted memory work is Frida, which injects a JavaScript agent into the target process and exposes a runtime API for hooking, tracing and memory access. The difference in approach is structural. Frida lives inside the target: its hooks are in-process, its Interceptor API rewrites functions at runtime, and its scripting model is JavaScript. The MCP bridge lives outside the target, in Cheat Engine, and drives the same debugger primitives a human would use: hardware breakpoints, scans, disassembly, RTTI lookups. It does not inject a runtime of its own; it asks Cheat Engine to do what Cheat Engine does.
That makes the bridge a better fit when you want the debugger's view (what instruction wrote this address, what does this function look like) and a worse fit when you want sustained instrumentation or a script that runs headless on a build server. Frida is scriptable without a GUI and without Windows; the bridge requires Cheat Engine running, and the native transport requires Windows. The other alternative is doing nothing new at all: Cheat Engine's own Lua console already exposes the same API, and the bridge's contribution is the MCP layer and the agent, not the primitives. If you are comfortable writing Lua by hand, the marginal gain is the natural-language loop, not capability.
Maintenance, licensing and what the version number implies
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; anything beyond it is a question for a lawyer, not for this article. The repository is not archived, and the last push recorded is 2026-08-14.
The README badge and the ping response both say version 12.0.0, and the pipe name embeds v99, so the transport identifier is decoupled from the release number. No releases were retrieved, which means versioning is happening in the repository rather than through tagged artifacts. That has a practical consequence: there is no changelog to read, so an upgrade means diffing the Lua bridge and the Python server yourself. The bridge is loaded by dofile from a path you control, so upgrading is a file replacement plus a reload in Cheat Engine, and the MCP server restarts with your IDE. The real maintenance cost is not the code, it is the coupling to Cheat Engine's API surface and to your target's memory layout, both of which move independently of this project.
Editorial conclusion
Adopt it if you already work inside Cheat Engine on Windows and want an agent to drive the same API you would call by hand; the named pipe path needs no extra daemon and the Lua bridge loads with a single dofile. Do not adopt it if your target is a remote or hostile host, if you cannot run Cheat Engine on the machine under analysis, or if you expect the tool list to be a stable interface: the README advertises roughly 180 tools and the excerpt names only a fraction of them, so read MCP_Server/ce_mcp_bridge.lua and mcp_cheatengine.py before you commit to a workflow. Verify first that your Cheat Engine build exposes File then Execute Script, and if you use the TCP relay, confirm what --host you bound and who can reach port 9876.
Community notes