Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
QA_HOMENoArtifacts root./qa
QA_CONFIGNoConfig file location./.qa/config.json
QA_ENGINENoEngine to use: playwright or electronplaywright
QA_CHANNELNoBrowser channel: chrome or msedgebundled Chromium
QA_HEADLESSNoHeaded vs headlessauto on CI=true
QA_ALLOW_HOSTSNoHosts the server may openloopback only
QA_NAV_TIMEOUT_MSNoPage load timeout30000
QA_ACTION_TIMEOUT_MSNoAction and wait timeout5000

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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
stage_openA

Open a URL in a real browser window owned by this server. The window is parked off-screen unless hidden=false. Returns a stage_id. Does not choose what to test.

stage_closeC

Close a stage and its browser context.

stage_focusB

Move a stage window from off-screen to the visible desktop and focus it.

stage_stateB

Report URL, viewport, hidden flag, last capture time, capture staleness, and runtime error counts for a stage.

actB

Execute the given click/fill/press/hover/select/scroll actions in order. No extra steps, no retries, no healing. Returns per-action ok/error/timing.

captureB

Take a PNG of the current stage and return it as an image block plus metadata. Reports when it was taken; it does not judge the frame.

wait_forB

Wait until a selector is visible or a text appears, up to timeout_ms. There is no implicit 'ready' heuristic.

measureB

Run rule-based measurements on the live page: horizontal overflow, broken images, missing alt, small tap targets, clipped text, plus collected console/page/network errors. Every rule returns its definition and threshold.

scenario_runB

Open a URL, execute the supplied steps exactly as written, capture the requested frames, and store a run under qa/runs/<run_id>. Steps are never invented, repaired, or retried.

diffB

Compare a named capture from a run with the promoted baseline for that scenario. Returns changed pixel counts and a bounding box, and writes a diff image. Does not decide if the change is acceptable.

findings_storeB

Persist findings supplied by the caller. Each finding needs a claim and at least one evidence reference. This stores; it does not grade, dedupe, or resolve.

annotate_startA

Open a visible window with a drawing overlay so the user can mark parts of the app and attach notes. Returns immediately; poll annotations_list until status is ready.

annotations_listC

List annotation sessions and their status. Marks and notes are returned verbatim.

annotations_getB

Return an annotation bundle with each mark's element, rect, note, and the cropped images of the marked regions.

annotations_resolveC

Mark an annotation as handled and record how it was addressed.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.3/5.0

Scored across 15 tools

Disambiguation4/5

Most tools have clearly distinct roles: stage lifecycle, act/capture/wait, annotation lifecycle, measurement, scenario runs, and diffing. There is minor overlap between act and scenario_run for executing steps, and between stage_state and measure for error reporting, but descriptions clarify the different scopes.

Naming Consistency3/5

Prefixes like stage_* and annotations_* help group related tools, but conventions are mixed: noun_verb (stage_open, annotations_get), verb_noun (annotate_start), and bare verbs (act, capture, diff, measure). The names remain readable but are not predictable throughout.

Tool Count5/5

Fifteen tools map cleanly to distinct QA capabilities—browser staging, interaction, capture, waiting, annotations, findings, measurement, scenario runs, and diffing. There is no obvious filler, and the count fits the server's apparent scope.

Completeness4/5

The core QA loop is covered: open/focus/close a stage, act, capture, wait, measure, run scenarios, diff, annotate, and store findings. However diff references a promoted baseline with no visible baseline promotion/management tool, and findings_store has no retrieval counterpart, leaving some workflow gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues