Building an MCP server for reverse engineering

I built a small bridge that lets Claude drive Perception like a debugger.

Perception is a native RE IDE – it does the hard part already (memory access, pattern scanning, disassembly, emulation, all on a live process). The MCP bridge is just an HTTP relay and a tool catalogue on top. 100+ tools at last count.

Two pieces

The Perception side is an AngelScript script. It attaches to a target, opens an HTTP server on :13340, and exposes the IDE's full toolset behind named commands. Worker threads handle the heavy stuff (big memory scans, value scans across modules) so the polling stays responsive.

The Node side is an Express server that speaks MCP. Tool calls become HTTP requests to the script. Smart timeouts – 2 minutes for reads, 5 for scans, because a value scan across a 200 MB module takes minutes. Try/catch around every scan and xref so an exception in the script doesn't kill the bridge.

The tools

100+, grouped roughly:

Memory: read, write, alloc, free.
Scans: patterns, strings, pointers, values, bool ranges, watch-for-changes.
Disasm: Zydis with full operand info, function boundary detection, an assembler, RIP resolver.
PE: section list, exports, imports, headers, vtables.
Xrefs: who calls/references what.
Unreal: resolve globals, FName/FString/TArray/UObject readers, walk class hierarchies, enumerate actors, read transforms.
Source 2: interface enumeration, schema dumps.
Emulation: Unicorn x86-64 with process-backed memory.
Hooking: IAT patches.
Live overlay: labels, boxes, lines, 3D world markers, address watches, struct visualisers.

Most of these compose from a handful of primitives, so adding new ones is just a new command handler.

What it actually does in practice

Ask "find the player entity list" on a UE game and Claude chains re_ue_resolve_globals → re_ue_find_actors → re_read_uobject → re_ue_dump_props → re_ue_read_fname. Two minutes, you've got a struct map. ReClass would take an hour.

Ask "where does the game read health" and it'll re_scan_value for candidates, re_watch_range to filter to the ones that actually change, re_xrefs_to to find the code that touches them, re_disassemble_function on each, then re_scan_pattern and re_scan_all_patterns to verify the signature is unique. Five minutes, you've got a stable pattern.

Ask "draw all the actors on screen" and it'll resolve GWorld, walk the actor list, read transforms, and call re_draw_world_marker per actor. Live overlay, no game mod.

Decisions worth flagging

HTTP polling instead of WebSocket. WebSocket had localhost binding issues on Windows and the polling overhead at 50 ms is invisible compared to the work the tools do.

Flat positional parameters (p0..p5) for command calls because Perception's HTTP handler doesn't parse JSON. The bridge maps named MCP arguments to positional ones transparently, so on the Claude side everything looks like a normal tool call.

Physical memory access via Perception's page table translation, not the Win32 API. You can write .text without a VirtualProtect. Less noisy.

No game-specific knowledge in the tools. They expose primitives only. All of "this is how UE5 lays out an FString" lives in the Claude conversation, not the bridge. Same code works on UE games, CS2, custom engines, system services.

What surprised me

Claude's good at this. Not just "fast at the tedious parts" – actually pattern-matches on memory dumps. Spots vtable pointers, FName indices, padding, flag fields, inheritance chains. Things that take an hour staring at ReClass.

The iteration loop is the unlock. Edit script, click Execute in Perception, the tool's live without restarting the game or losing my attachment. The IDE has memory viewing, disasm overlays, a pattern scanner. The MCP bridge is orchestration on top of that.