Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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). leaks lists dev-only code found in the output; it must be empty.

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 repro: a scenario file that replays it exactly. Pass that file to run_scenarios to reproduce, then again after fixing to verify. The same seed gives the same inputs.

game_startA

Connect to the game. auto (default): attach to the human's live game if debuff dev has it open in a browser, else start a private headless copy, paused. Returns the mode, state and how many notes the human has flagged. Replaces any running session.

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 toTick (default: now), saved as a scenario in .debuff/replays/ that replays it exactly. Use a note's tick to reproduce what the human saw when they flagged it, then run_scenarios with the returned file. warnings lists anything a replay can't reproduce (for example slow motion).

game_rewindA

Live mode only. Take the human's game back (or forward, within the known session) to tick: the page reloads, replays the session's inputs to that tick and stays paused, so the state is exactly what it was then. Use a note's tick to look at the moment the human flagged. The page needs a second to reload; then use game_state or game_capture.

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

NameDescription
playtestPlay the game, look for bugs and rough edges, and report findings with evidence.
fix-errorsRead the explained runtime errors, fix the ones in this game's code, and verify.
tune-feelPropose param changes for a feel goal, try them live, and let the human choose.
add-mechanicImplement a gameplay mechanic in small steps, with a logic test that proves it works.
explain-stutterFind out why frames drop, and whether the game or something outside it is the cause.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 21 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues