Savecraft is an open-source MCP server that parses game save files and serves structured game state to AI assistants. Point it at your save directory and your LLM can help you with gear, stats, skills, quest progress, everything. Upload a build note and get detailed and specific advice about how to optimize your game.
I built this because I got tired of screenshotting my inventory every time I wanted to compare two items in Diablo 2: Resurrected (and am too garbage at the game myself to make the distinction). A local Go daemon watches save directories with fsnotify, parses files through sandboxed WASM plugins, and pushes structured state to Cloudflare Workers over binary protobuf WebSocket.
Every plugin binary is Ed25519 signed: community contributors submit source, CI builds and signs the WASM with a key they never touch. Your machine verifies before execution. This was the only trust model I'd accept for running other people's code on my gaming rig.
Server side is Cloudflare Workers + Durable Objects with WebSocket Hibernation, D1 with FTS5 for full-text search across saves and notes, and reference data modules (like a D2R drop calculator) running as separate WASM Workers via Workers for Platforms dispatch namespaces.
Currently supports Diablo II: Resurrected, Clair Obscur: Expedition 33 (what I'm playing currently!), Stardew Valley (theoretically), and WoW (Battle.net API + Raider.io). Linux and Windows are solid, Mac is kind of undertested. Apache 2.0, solo project. The marketing site is https://savecraft.gg
Oh this is really interesting! I hadn't explored Steam Cloud as a data source. Currently the daemon watches local save directories and parses through WASM, but if Steamworks exposes an API to pull save files remotely, that could work as a server-side adapter (same pattern I use for WoW via Battle.net API). That would eliminate the daemon entirely for Steam games, which is by far the biggest friction point in the install flow right now.
I'd love to see your JS lib if you're willing to share it! The raw files would still need per-game parsers (D2R's .d2s is a gnarly bit-packed binary, for example), but moving file access to the server side would be a big deal for adoption.
Neat application of WASM! Did the lack of WA component support cause you any issues? Curious to see how you handled streaming of save data for games with unwieldy files. Off to the source code I go!
Cool use case. One thing worth thinking about with any MCP server that does file parsing — the tool definitions themselves can be a security surface. Things like path parameters without validation, or deserialization from untrusted save files. Even "read-only" MCP servers can be vectors if an attacker controls the input file. Not specific to your project, just something I've been seeing across a lot of MCP implementations.
Savecraft is an open-source MCP server that parses game save files and serves structured game state to AI assistants. Point it at your save directory and your LLM can help you with gear, stats, skills, quest progress, everything. Upload a build note and get detailed and specific advice about how to optimize your game.
I built this because I got tired of screenshotting my inventory every time I wanted to compare two items in Diablo 2: Resurrected (and am too garbage at the game myself to make the distinction). A local Go daemon watches save directories with fsnotify, parses files through sandboxed WASM plugins, and pushes structured state to Cloudflare Workers over binary protobuf WebSocket.
Every plugin binary is Ed25519 signed: community contributors submit source, CI builds and signs the WASM with a key they never touch. Your machine verifies before execution. This was the only trust model I'd accept for running other people's code on my gaming rig.
Server side is Cloudflare Workers + Durable Objects with WebSocket Hibernation, D1 with FTS5 for full-text search across saves and notes, and reference data modules (like a D2R drop calculator) running as separate WASM Workers via Workers for Platforms dispatch namespaces.
Currently supports Diablo II: Resurrected, Clair Obscur: Expedition 33 (what I'm playing currently!), Stardew Valley (theoretically), and WoW (Battle.net API + Raider.io). Linux and Windows are solid, Mac is kind of undertested. Apache 2.0, solo project. The marketing site is https://savecraft.gg
What about parsing steam saves? Steamworks SDK provides an api to query file names and then you can read them.
Actually i have a js lib which can do that part, but steam should be running under particular steam user for whom saves are parsing.
Oh this is really interesting! I hadn't explored Steam Cloud as a data source. Currently the daemon watches local save directories and parses through WASM, but if Steamworks exposes an API to pull save files remotely, that could work as a server-side adapter (same pattern I use for WoW via Battle.net API). That would eliminate the daemon entirely for Steam games, which is by far the biggest friction point in the install flow right now.
I'd love to see your JS lib if you're willing to share it! The raw files would still need per-game parsers (D2R's .d2s is a gnarly bit-packed binary, for example), but moving file access to the server side would be a big deal for adoption.
Here it is: https://github.com/ArtyProf/steamworks-ffi-node
Actually I develop it mostly for steam integration in games under js.
I think the tricky thing left is in what format devs saving files to parse them correctly.
But generally it can parse most indie games, which are using steam remote storage api and store them as json.
The main requirement that steam must be launch for the user that MCP is parsing
Here is the doc for steam remote storage API: https://github.com/ArtyProf/steamworks-ffi-node/blob/main/do...
Neat application of WASM! Did the lack of WA component support cause you any issues? Curious to see how you handled streaming of save data for games with unwieldy files. Off to the source code I go!
[dead]
Cool use case. One thing worth thinking about with any MCP server that does file parsing — the tool definitions themselves can be a security surface. Things like path parameters without validation, or deserialization from untrusted save files. Even "read-only" MCP servers can be vectors if an attacker controls the input file. Not specific to your project, just something I've been seeing across a lot of MCP implementations.
[dead]