Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Drive a running tModLoader (Terraria) instance from an agent: launch, query, screenshot, read state.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"tmodloader": {
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}在终端中运行这条命令
claude mcp add tmodloader -- uvx tmodloader-mcp粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"tmodloader": {
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"tmodloader": {
"type": "stdio",
"command": "uvx",
"args": [
"tmodloader-mcp"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 musharna 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.6.3)于2个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Verbaly
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
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.
i18n for coding agents: extract, check and translate an app's text, with drafts a person approves
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
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
只显示了开头部分;其余内容请在仓库中阅读