Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Deterministic Brotato theorycrafter MCP server: facts and math, not guesses.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
SPUDCOACH_DATADu brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"spudcoach": {
"command": "uvx",
"args": [
"spudcoach"
],
"env": {
"SPUDCOACH_DATA": "your-value"
}
}
}
}Führe das in deinem Terminal aus
claude mcp add spudcoach --env SPUDCOACH_DATA=your-value -- uvx spudcoachTrag die leeren Werte ein, bevor du ihn startest.
In .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"spudcoach": {
"command": "uvx",
"args": [
"spudcoach"
],
"env": {
"SPUDCOACH_DATA": "your-value"
}
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"spudcoach": {
"type": "stdio",
"command": "uvx",
"args": [
"spudcoach"
],
"env": {
"SPUDCOACH_DATA": "your-value"
}
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
SPUDCOACH_DATA envDiese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 7. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto BrendanL79 bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.11.0) kam vor 4 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Python (uv) auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, Asset Notation
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
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.
Read and maintain an Asset Notation file on disk: net worth, holdings, valuations, CSV import.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
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,
Nur der Anfang wird gezeigt; den Rest findest du im Repo