qa-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QA_HOME | No | Artifacts root | ./qa |
| QA_CONFIG | No | Config file location | ./.qa/config.json |
| QA_ENGINE | No | Engine to use: playwright or electron | playwright |
| QA_CHANNEL | No | Browser channel: chrome or msedge | bundled Chromium |
| QA_HEADLESS | No | Headed vs headless | auto on CI=true |
| QA_ALLOW_HOSTS | No | Hosts the server may open | loopback only |
| QA_NAV_TIMEOUT_MS | No | Page load timeout | 30000 |
| QA_ACTION_TIMEOUT_MS | No | Action and wait timeout | 5000 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
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.
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.
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.
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.