FIREFIGHTER
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FIREFIGHTER_HOME | No | Overrides the state folder location (defaults to %LOCALAPPDATA%\firefighter on Windows, ~/Library/Application Support/firefighter on macOS, or ~/.local/state/firefighter on Linux). |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| firefighter_submitA | Queue heavy work (GPU, or CPU over ~1 min) on this shared machine. Returns one line: job id, start estimate, cost, do: (next step). Then call firefighter_wait. Runs the command as you, outside any agent sandbox, with your network and files: only submit what you'd run in your own shell. |
| firefighter_waitA | Wait up to ~45 s on a job. One line, short if nothing changed; receipt and log tail when done. |
| firefighter_statusA | The shared machine in a few lines: the human, what runs until when, the queue, budgets, plans, do:. Pass minutes (and gpu) to also price a job without queuing it. |
| firefighter_jobB | Change your job: extend (minutes = more lease), urgent / normal (tier, while waiting), cancel. |
| firefighter_planB | Announce heavy work later so others plan around it (reserves nothing). done=true removes your project's plans. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool covers a distinct phase of the job lifecycle: submit queues work, wait blocks for completion, status reports the machine, job mutates an existing job, and plan announces future intent. The only mild overlaps are wait vs. status (both surface job state) and status's pricing mode vs. submit, but the descriptions make the boundaries clear enough.
All tools share a consistent firefighter_ prefix, giving a predictable namespace. The suffixes mix verbs (submit, wait) with nouns (status, job, plan), so the pattern isn't a pure verb_noun scheme, but it is readable and internally coherent.
Five tools is well-scoped for a shared-machine job queue: submit, wait, inspect, modify, and plan. Each tool maps to a real user need with no filler.
The surface covers the full lifecycle: queue, poll, inspect, mutate (extend/tier/cancel), and pre-announce plans. Minor gaps exist—no explicit way to list your own jobs or fetch full logs on demand (logs surface only via wait's tail), but agents can work around this with status and repeated waits.