Skip to main content
Glama
Jamickin

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