debuff
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| inspect_projectC | Summary of the project: dependencies, plugins and their contributions, assets, last build size. |
| list_assetsB | Run the asset pipeline: every asset id, type, size and importer, plus generated files, warnings and possibly unused ids. |
| buildA | Build for production and return the size report (raw, gzip, brotli per file). |
| run_testsA | Run the logic tests in tests/**/*.test.ts (keiko): the real game in Node, no browser, in milliseconds. Each failure has its message, the source line, and the game's tick, scene and state when it failed. Use after every change; write a test for each mechanic you add. |
| run_scenariosB | Run scenarios/*.json (or the given files) in a headless browser. Returns per-step results, runtime errors, captures and final state. |
| fuzzA | Play the game headlessly with random but plausible input (movement keys held, action keys tapped) to find runtime errors, stuck states and back-and-forth loops. Each finding includes the explained error (kind, source-mapped file:line, hint) and |
| game_startA | Connect to the game. auto (default): attach to the human's live game if |
| game_stateB | Current scene, tick, time, renderer, frame stats, the scene's inspect() data and plugin inspect data. |
| game_stepA | Advance the simulation by fixed steps (60 per second by default) and return the new state. |
| game_inputA | Keyboard or pointer input. press/release take a KeyboardEvent.code (e.g. Space, ArrowLeft, KeyZ). tap/pointer_down/pointer_move take logical x, y. Input takes effect on the next game_step. |
| game_paramsB | Every tunable param group: schema (type, default, min, max, units, description) and current values. |
| game_set_paramA | Set a tunable param live. Values are validated against the param's type and range. Changes last until game_start or a reload. |
| game_captureB | Screenshot of the current frame as a PNG image. |
| game_pauseA | Pause or resume a live game (headless games are always paused). game_step also pauses first. |
| game_framesA | Recent frames, oldest first: intervalMs (what the player feels), updateMs, renderMs, steps (>1 means catching up), quads, drawCalls and longTaskMs (browser-reported main-thread stalls). Use it to explain stutter; in headless mode times reflect stepping, not real play. |
| game_profileA | Why the game stutters, from myaku: frame-time percentiles (p50/p95/p99), hitches per minute, and the worst hitches explained. Each has a cause (script, gc, upload, compile, layout, throttled, hidden, unknown), a confidence, the script and function to look at when known, and a hint. Spans show time in debuff's update and render. Prefer this over game_frames to explain stutter; measure in live mode, since headless stepping doesn't reflect real play. |
| game_notesA | Moments the human flagged in the overlay (live mode): their words, the tick, the scene's inspect() state then, and the frames leading up to it. |
| game_replayA | Everything played since the game loaded (keys, pointer, param changes) up to |
| game_rewindA | Live mode only. Take the human's game back (or forward, within the known session) to |
| game_errorsA | Runtime errors since the game started, explained: kind (your-code, debuff-usage, debuff-bug, outside), where (source file:line, source-mapped), a hint, the loop phase and tick, and a repeat count. A loop error stops the game; fix it, then game_pause false to resume. For debuff-bug, tell the human and share reportUrl rather than working around it. |
| game_stopA | Headless: close the browser and dev server. Live: resume the human's game and disconnect. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| playtest | Play the game, look for bugs and rough edges, and report findings with evidence. |
| fix-errors | Read the explained runtime errors, fix the ones in this game's code, and verify. |
| tune-feel | Propose param changes for a feel goal, try them live, and let the human choose. |
| add-mechanic | Implement a gameplay mechanic in small steps, with a logic test that proves it works. |
| explain-stutter | Find out why frames drop, and whether the game or something outside it is the cause. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Most tools have clearly distinct purposes, and descriptions actively disambiguate overlapping ones (game_profile says 'prefer this over game_frames'). A few frame/state inspection tools (game_frames, game_profile, game_state, game_capture) sit close together, but the descriptions steer selection well. game_replay vs game_rewind are clearly differentiated by their docs.
Strong, readable convention: a game_ prefix groups all live-game tools (game_start, game_step, game_input, game_pause, etc.) with consistent snake_case verb/noun forms. Project/build/test tools (inspect_project, list_assets, build, run_tests, run_scenarios, fuzz) drop the prefix but remain snake_case and predictable. Minor deviation in grouping rather than style.
21 tools is on the heavier side but justified by a broad domain spanning project inspection, asset/build, live game control, testing, fuzzing, and profiling. Each tool maps to a distinct capability rather than being redundant. Slightly high, but no filler.
The surface covers a full debugging lifecycle: inspect project/assets, build, connect/step/input/pause the game, capture state and frames, profile stutter, record/rewind replays, capture errors, run tests and scenarios, and fuzz. Tunable params have both read (game_params) and write (game_set_param). Minor gaps only, e.g. no explicit teardown/scaffold for new projects.