mod-dev-mcp

A small MCP (Model Context Protocol) dev-tooling server for the tModLoader mod projects in this workspace (Ben10Mod, MistbornModOwnBlend). Registered workspace-wide via ../.mcp.json so Claude Code auto-connects.

It does not connect to a running game — it's build/format/log tooling only.

Tools

• build_mod { modPath, configuration? } — runs dotnet build, returns structured diagnostics from both build passes (see below), whether a .tmod was produced, and a tail of raw output.
• format_mod { modPath, check? } — runs CSharpier.
• tail_tmodloader_log { lines?, logFile? } — tails tModLoader's client/server log.
• check_environment {} — reports .NET SDK presence, whether the workspace tModLoader.targets and the official ModSources/tModLoader.targets exist, and whether the Ben10Mod/MistbornModOwnBlend symlinks in ModSources resolve correctly.

Why two-pass diagnostic parsing

dotnet build on a tModLoader mod runs an ordinary C# compile, then (if that succeeds) a nested dotnet tModLoader.dll -build ... packaging step that produces the .tmod. Ordinary compile errors come back as standard MSBuild diagnostics (file(line,col): error CSxxxx: ...); packaging-level failures (missing native libraries, mod locked by a running game, bad build.txt/.hjson/textures) come back in tModLoader's own differently-shaped log lines instead (tModLoader : Mod Build error TMLxxx: ...). src/parsers/msbuildDiagnostics.ts handles both and tags each diagnostic's source accordingly. It was built against real captured samples of both failure shapes, not assumed formats — see ../Ben10Mod/CLAUDE.md for the environment quirks that produced them (missing DYLD_LIBRARY_PATH for headless builds, and the "close tModLoader before building via CLI" conflict).

Development

npm install
npm run build   # compiles to dist/
npm run dev      # run directly via tsx without building

The server communicates over stdio, so it's not meant to be run standalone outside an MCP client — npm run dev/npm start will just sit waiting for a client to connect.