Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Drive a running tModLoader (Terraria) instance from an agent: launch, query, screenshot, read state.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"tmodloader": {
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}Run this in your terminal
claude mcp add tmodloader -- uvx tmodloader-mcpPaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"tmodloader": {
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"tmodloader": {
"type": "stdio",
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 7, 2026
The registry name was verified with the GitHub account musharna, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.6.3) reached the registry 2 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Python (uv) on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, Microsoft Exchange Online MCP
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Exchange Online admin for MSPs: forwarding audits, EWS posture and offboarding, no PowerShell
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
tmodloader-mcp
Drive a running tModLoader instance from an agent — launch it, ask it questions, photograph it, and read its state back as structured data.
How it works · Quick start · Configuration · Known limits
Game engines have grown MCP servers — Unity, Unreal, Godot and Defold all have one, so an assistant can see a real scene instead of guessing from a prompt. tModLoader has not had one. This is that.
The tool staged its own screenshot — time:noon , teleport:spawn , spawn:1,25 , shot:full — read from the game's back buffer, so a window in front of the game cannot be in the picture ( How it works starts there). Trimmed of the unexplored dark below the terrain; otherwise exactly as returned.
Status: alpha — it has only ever run on one install; see
Known limits before adopting it. Nothing defaults to
anybody's install, the mod-side half is a folder you vendor
(
responder/),
and CI compiles it with nothing of any mod's on the compile line.
uv tool install tmodloader-mcp # or: pip install tmodloader-mcp
export TMODLOADER_SAVE_DIR="/mnt/c/Users/ /Documents/My Games/Terraria/tModLoader" export TMODLOADER_MOD_SOURCE="$TMODLOADER_SAVE_DIR/ModSources/ "
Then:
responder/ into your mod's source tree and subclass DevResponder. It is a folder of C#, not a PyPI dependency, because it compiles inside your mod.launch, then diag. Or open with the start_a_session prompt, which lists the worlds and characters that actually exist here.This needs WSL2 driving a Windows tModLoader — Requirements says why before anything else does.
The game is asked by writing a file it polls, not by sending it input:
┌─────────────────────────────────────────────────────┐
│ an agent — Claude Code, or anything speaking MCP │ └──────────────────────┬──────────────────────────────┘ │ tools · prompts · capture:// resources ┌──────────────────────▼──────────────────────────────┐ │ tmodloader-mcp — this package (Python, WSL2) │ └──────────────────────┬──────────────────────────────┘ │ writes -capture.trigger │ reads -diag- .txt, │ -shot- .png, ... ┌──────────────────────▼──────────────────────────────┐ │ the tModLoader save directory │ │ plain files on disk — no socket, no keystrokes │ └──────────────────────▲──────────────────────────────┘ │ polls every few frames, writes │ each answer next to its trigger ┌──────────────────────┴──────────────────────────────┐ │ DevResponder — C# you vendor into YOUR mod, │ │ inside tModLoader, a real game, on Windows │ └─────────────────────────────────────────────────────┘
No synthetic keystrokes, no window focus, and nothing that can be fooled by another window sitting on top of the game. That last point is the reason for the design: OS-level screen capture was tried first and returned a picture of Discord — a window in front of the game — while passing every check available. Reading the game's own back buffer cannot contain another window by construction, not by luck.
Captures name a region and have no default. The frame holds only the game, but that still includes a character name, a world name and any chat on screen, so a request says which corner it wants.
The mod side of that protocol — every filename, what each one contains, and which failures it has to be able to express — is written down in docs/MOD_CONTRACT.md, and implemented in responder/. You can read the contract or vendor the folder; the folder is the same document with a compiler checking it.
Since 0.6.0 replies are tagged: a request may carry a short id the responder echoes back first, so a late answer can never be mistaken for the next request's. Older vendored copies keep working — the tag is only sent to a responder that advertises taking it.
These are verbs, driven through the trigger tool, not separate MCP tools.
The reads come with the base class — every consumer serves them, and vendoring an upgrade can never hand your mod a power it did not have before:
| Verb | What it answers |
|---|---|
capture / shot | a photograph of the frame, by named region |
diag | whatever your mod chose to report |
tiles | tile-type counts in a rectangle |
entities | NPC, item or projectile counts, filterable by rectangle |
find | one line per entity: id, position, health |
players | who is connected |
The writes are opt-ins, each one line you write in RegisterCommands:
| Opt-in | Verbs it adds |
|---|---|
DevMutations | time weather spawn give teleport settile cleartile despawn |
DevCommandBridge | command commandlist — runs any mod's own registered ModCommands |
DevChat | chat say |
One line each is deliberately the whole mechanism: not a setting, not a marker file, not an environment variable, because each of those can be switched on somewhere other than the source somebody will read when they ask why an NPC appeared in their world. responder/README.md has the detail, including why DevCommandBridge is the answer to "what about an escape hatch" and why there is no reflect_invoke here.
Every line below is real — the same server and client the live checks drive, quoted rather than paraphrased:
spawn:1,20 OK: spawned 20 of 20 id=1 at tile 2101,252
time:dusk sent to a CLIENT: REFUSED: "time" changes something the SERVER owns, and a client that changed it would be corrected by the next world packet - the change would appear to work and then undo itself. Send this to the server: time@ .
give:8,5 sent to the SERVER: REFUSED: "give" needs a local player, and a dedicated server has none - it runs the world without standing in it. Ask a client, by name.
spawn:0,1 REFUSED: 0 is not a NPC id - it is how Terraria spells "nothing", so this would have succeeded and done nothing
spawn:banana,5 REFUSED: "banana" is not a positive whole NPC id
time:teatime REFUSED: "teatime" is not one of dawn, noon, dusk, midnight
tiles:0,0,1000,1000 REFUSED: 1000 by 1000 is 1000000 tiles, past the limit of 16384 one query may scan
The refusals are the point. Each one says what was wrong, what would have been right, and — when the verb belongs to the other side of the wire — where to send it instead, because the reader is an agent and an agent retries exactly as well as the refusal explains.
Most of what this does _could_ be a CLI, and where that is true it should stay one — a stateless local binary does not need a protocol in front of it. What earns the surface here is that a running game is not stateless:
A session
| Tool | What it buys over bash |
|---|---|
launch / stop | Session state across calls |
join | A second client into a session that is already running |
status | Asking whether a session exists without provoking an error |
restart | stop → build → launch in the one order that works |
inventory | The worlds, characters and mods launch needs and cannot check |
Asking the game
| Tool | What it buys over bash |
|---|---|
trigger | The write → poll → timeout → clean-up loop, written once |
commands | What the mod says it serves, read from the mod, not a copy here |
diag | Structured fields AND the records under them, not text to sed |
wait_until | Waiting for a state on one budget, instead of sleeping a guess |
heartbeat | WHICH silence — absent, stale, still loading, or not armed |
Pictures
| Tool | What it buys over bash |
|---|---|
shot | A path per call, a whole PNG behind it, refusals as refusals |
captures | Which captures exist, as names — a reader that takes no paths |
read_capture | The picture itself, for an agent not on this machine |
prune_captures | Removing captures without a delete loose enough to reach a world |
Logs
| Tool | What it buys over bash |
|---|---|
logs | Any log, filtered — including the run that already rotated away |
log_files | Which logs exist right now, and how many old runs are archived |
log_since | Only what a log gained, and whether it rotated under you |
log_watch | Blocking until a line appears, instead of a guessed sleep |
Building, the API, and the saves
| Tool | What it buys over
Only the beginning is shown; read the rest in the repo