Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Descripción del creador (original en inglés)
Drive a running tModLoader (Terraria) instance from an agent: launch, query, screenshot, read state.
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
Necesitas
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Abre Claude Desktop → Settings → Developer → Edit Config y pega esto en claude_desktop_config.json
{
"mcpServers": {
"tmodloader": {
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}Ejecuta esto en tu terminal
claude mcp add tmodloader -- uvx tmodloader-mcpPégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"tmodloader": {
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"tmodloader": {
"type": "stdio",
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Este se ejecuta en tu computadora, y ChatGPT solo puede conectarse a servidores en internet. Elige otra app.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Se ejecuta en tu computadora; la lista de herramientas aparece en tu app de IA después de instalarlo.
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 7 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub musharna, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Este se ejecuta en tu computadora; no hay endpoint en internet
Se ejecuta en tu computadora y usa ajustes locales en su lugar
Se ejecuta en tu computadora; solo podemos leer listas de herramientas de endpoints en internet
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.
Se ejecuta en tu computadora. Tu app de IA lo inicia cuando hace falta, y los datos no pasan por los servidores del creador (a menos que el propio servidor llame a un servicio en línea).
El repo de GitHub cambió por última vez –, y la última versión (0.6.3) llegó al registro hace 2 meses.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. También necesitas Python (uv) en tu computadora.
En la misma categoría: Spec Driven Development, Remote Desktop Commander, Georgia MCP
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
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.
An MCP server for Georgian public data, read from the organizations that publish it.
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
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
Solo se muestra el principio; lee el resto en el repo