mod-dev-mcp
by Jamickin
README.md
# 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
```bash
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.
TDQS
A3.8/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of confusion between tools. The single tool has a clear, distinct purpose.
Naming Consistency5/5
The single tool 'check_environment' follows a consistent verb_noun pattern, which is clear and predictable.
Tool Count2/5
A single tool for a mod development server is too few; a server of this scope would typically require multiple tools for building, testing, and managing configurations.
Completeness2/5
The tool only checks the environment status, leaving out essential operations like building or deploying mods, which are likely needed for the server's purpose.
Maintenance
ActivityStale
ResponsivenessNo issues