Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Deterministic Brotato theorycrafter MCP server: facts and math, not guesses.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
SPUDCOACH_DATA你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"spudcoach": {
"command": "uvx",
"args": [
"spudcoach"
],
"env": {
"SPUDCOACH_DATA": "your-value"
}
}
}
}在终端中运行这条命令
claude mcp add spudcoach --env SPUDCOACH_DATA=your-value -- uvx spudcoach运行前请先填写空着的值。
粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"spudcoach": {
"command": "uvx",
"args": [
"spudcoach"
],
"env": {
"SPUDCOACH_DATA": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"spudcoach": {
"type": "stdio",
"command": "uvx",
"args": [
"spudcoach"
],
"env": {
"SPUDCOACH_DATA": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
SPUDCOACH_DATA env这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月8日
注册名称已通过 GitHub 账户 brendanlefebvre 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.14.1)于3个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
同一分类中有:Spec Driven Development, Remote Desktop Commander, MyGroceryPal
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ 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.
UK supermarket prices: compare products and baskets across 13 stores, see price history, set alerts.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
A deterministic theorycrafter for Brotato, delivered as an MCP server you can chat with from Claude Code (and other MCP clients).
The design principle: a deterministic core holds the ground truth — weapon/item/character data, DPS formulas, stat mechanics — so the language model *looks facts up and computes* instead of recalling (and misremembering) them. Every tool returns a finished, verifiable answer or a structured error; there are no baked-in tier lists or opinions, only facts and math.
The dataset (data/brotato.json) is not committed — it is derived from copyrighted game files, so you build it yourself from a local Brotato install (see Building the dataset). A full build from Brotato 1.1.15.4 contains 202 weapons, 197 items, 50 characters, and 15 weapon-class sets.
uv for environment/dependency managementInstall dependencies:
uv sync
Build the dataset (needs a local extraction — see Building the dataset), then start the server:
uv run python build_dataset.py # writes data/brotato.json
uv run python -m brotato_coach.server # starts the MCP server over stdio
The server refuses to start without data/brotato.json and tells you to build it first.
Run the tests (the dataset-dependent integration test is skipped when no dataset is built):
uv run pytest # 89 tests (88 passed + 1 skipped without a built dataset)
uvx spudcoach --data /path/to/brotato.json
The dataset is never distributed — build your own from your Brotato install: uv run python build_dataset.py (see docs/extraction-setup.md). Game version auto-detects from the decompiled recovered/singletons/progress_data.gd, and generated_at defaults to the current UTC time — pass --game-version/--generated-at explicitly to override either. SPUDCOACH_DATA works as an env-var alternative to --data.
The MCP server is described by plugin/.mcp.json:
{
"mcpServers": { "spudcoach": { "command": "uv", "args": ["run", "python", "-m", "brotato_coach.server"], "cwd": "${CLAUDE_PLUGIN_ROOT}" } } }
The server reads the (locally built) data/brotato.json relative to its working directory, so it must run with the repository root as its `cwd` (the manifest handles this via ${CLAUDE_PLUGIN_ROOT} when bundled as a plugin), and you must build the dataset first.
To register it directly in Claude Code without packaging, add the server pointed at your checkout, e.g.:
claude mcp add spudcoach -- uv run --directory /path/to/spud-coach python -m brotato_coach.server
Once connected, just ask in natural language — the model routes your question to the tools below:
Claude Desktop can launch the server with uvx in two forms: fetch straight from this repo (auto-updates on restart, but needs git reachable — see the Windows note below), or point at a local checkout (nothing fetched at runtime; the most reliable form on Windows). Either way you supply your own locally built brotato.json — the dataset is never distributed.
uv on the machine running Claude Desktop (winget install astral-sh.uv on Windows, or the standalone installer).spud-coach server:%APPDATA%\Claude\claude_desktop_config.json~/Library/Application Support/Claude/claude_desktop_config.jsonFetch-from-repo form:
{
"mcpServers": { "spud-coach": { "command": "uvx", "args": [ "--from", "git+https://github.com/brendanlefebvre/spud-coach", "spudcoach", "--data", "C:\\Users\\ \\path\\to\\brotato.json" ] } } }
Point --data at your built dataset (SPUDCOACH_DATA works as an env-var alternative). On macOS use a POSIX path like /Users/ /brotato.json.
uvx not found)The git+https://… form makes uv shell out to a git executable. Claude Desktop does not pass your shell — or even your System `PATH` — to the MCP subprocess; it spawns servers with its own trimmed environment. (The PATH it prints in the logs is its command-resolution list, *not* what the child process receives.) So a git that runs fine in PowerShell, installed in a System-PATH directory, can still come back "not found" here — and a bare "command": "uvx" can fail to resolve for the same reason. Two fixes:
--from instead of --from git+…: git clone https://github.com/brendanlefebvre/spud-coach C:\Users\<you>\src\spud-coach
{
"mcpServers": { "spud-coach": { "command": "uvx", "args": ["--from", "C:\\Users\\ \\src\\spud-coach", "spudcoach", "--data", "C:\\Users\\ \\path\\to\\brotato.json"] } } }
Update later with git pull in that folder, then restart Desktop.
git+https form and add an env block that hands the child an explicit PATH — git, plus uv's bin and the winget-links dir: "env": {
"PATH": "C:\\Program Files\\Git\\cmd;C:\\Users\\ \\.local\\bin;C:\\Users\\ \\AppData\\Local\\Microsoft\\WinGet\\Links;C:\\Windows\\System32" }
If uvx itself still isn't found, also set "command" to its absolute path (Get-Command uvx to locate it, e.g. C:\Users\ \AppData\Local\Microsoft\WinGet\Links\uvx.exe).
All tools return a JSON object. Lookups that miss return {"error": "not_found", "did_you_mean": [...]}.
22 tools. Arguments marked ? are optional.
| Tool | Arguments | Returns |
|---|---|---|
read_me | — | Session-start primer: how Brotato's core loop works, the source-verified stat mechanics, and what every precomputed field assumes. Call once, before anything else |
| Tool | Arguments | Returns |
|---|---|---|
get_weapon | name, tier? | Weapon record incl. raw stat-aware fields, on-hit effects, and weapon-class sets; {matches:[...]} if tier omitted and several tiers match |
get_item | name | Item record: effects, tags, archetype, frozen_stat |
get_character | name | Character kit: wanted_tags, banned_item_groups, flat_bonuses, gain_modifiers, special_effects, class_bonuses, starting_weapon_pool |
get_weapon_class_set | class_name | Weapon-class set bonuses (Blade, Gun, Elemental, …), by equipped count |
list_weapons | scaling_stat?, tier? | {weapons:[...]} filtered summaries |
list_items | tag?, scaling_stat?, archetype?, tier? | {items:[...]} filtered summaries |
list_characters | scaling_stat?, wanted_tag?, banned_item_group?, special_effect?, class_bonus_set?, can_start_with?, detail? | {characters:[...]} — full records, not summaries (see below) |
get_filter_options | — | Valid filter values in the dataset: item tags, archetypes, scaling stats, tiers, weapon-class names, enemy abilities / attack kinds / zones, and the character filter vocabularies |
| Tool | Arguments | Returns |
|---|---|---|
weapon_dps | name, tier, stats, aoe_enemies_hit?, character?, weapon_count?, engagement_distance?, loadout?, apply_set_bonuses? | Realized, stat-aware DPS at your build, split into base_dps + proc_dps, with a cadence breakdown and the assumptions baked in |
compare_weapons | names_with_tiers, stats, plus the same optional arguments as weapon_dps | {ranking:[...]} sorted by DPS descending, at one shared stat block |
compare_merge_paths | weapon_name, path_a, path_b, stats? | Winner or crossover_rd for two tier-merge paths (lists of tiers) |
stat_gradient | weapons, stats, step?, character?, aoe_enemies_hit?, engagement_distance? | Which stat to buy next: stats ranked by the DPS gain from +step of each. DPS only — survivability is out of scope |
| Tool | Arguments | Returns |
|---|---|---|
evaluate_item_for_build | item_name, character_name, current_stats | Per-effect verdict — live / wasted / harmful — with reasons, plus a summary |
loadout_set_bonuses | weapon_names | Per-class set progress across a whole loadout: equipped count, active bonuses, and next threshold |
explain_stat | stat | Verified stat mechanics: caps, special behavior, neglectable / never-negative flags |
stat_display_value | character, stat, raw_value | Displayed value after the character's gain modifiers (e.g. Ranger RD 6 → 9) |
| Tool | Arguments | Returns |
|---|---|---|
get_enemy | name, wave? | Enemy record: base stats, per-wave stat slopes, attack profile, ability tags. Pass wave (1-20) to also resolve effective stats at that wave |
list_enemies | appears_in?, ability?, attack_kind? | {enemies:[...]} filtered summaries |
wave_composition | wave, danger? | Base-game (Crash Zone) composition for a wave: enemy groups, base counts, first-spawn timing, repeats |
| Tool | Arguments | Returns |
|---|---|---|
evaluate_run | path? or run_json? | One-call post-mortem of a whole Brotato run.json save: run context (character, wave, danger), realized stats, weapon-DPS ranking, set progress, and per-item verdicts |
check_dataset_version | — | game_version, generated_at, schema_version |
Batch lookups. get_weapon, get_item and get_character accept name as either a string or a list of strings. A list returns {"results": [...]} in the order given, each entry a record or its own not_found — so detail on several entities costs one round-trip, not N.
`list_characters` returns full records, unlike list_weapons / list_items, which return summaries. The whole 50-character corpus is only ~7.7K tokens, so a survey answers in a single call with no follow-up get_character; pass detail="summary" for {id, name} rows instead. Its scaling_stat filter is a derived union — characters have no scaling-stat field — matching a positive stat-gain modifier, a positive flat bonus, or a matching wanted_tag. Each matched record carries a scaling_match object naming which signal fired, e.g. Engineer {"gain_pct": 25, "flat": 10, "wanted": true} vs Technomage {"wanted": true}, so the derivation is visible rather than asserted. Characters *penalised* in that stat are excluded from the match.
starting_weapon_pool is the run-start weapon-selection pool, not a fixed starting weapon: most characters offer a dozen or more, Arms Dealer offers only the Pistol,
只显示了开头部分;其余内容请在仓库中阅读