qa-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QA_MCP_CONFIG | No | Path to the qa.config.json file. Defaults to ./qa.config.json. | |
| QA_CLIENT_SECRET | No | Client secret for authentication, referenced by the config as env:QA_CLIENT_SECRET. | |
| QA_ADMIN_PASSWORD | No | Password for the admin role, referenced by the config as env:QA_ADMIN_PASSWORD. | |
| QA_CUSTOMER_PASSWORD | No | Password for the customer role, referenced by the config as env:QA_CUSTOMER_PASSWORD. |
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 |
|---|---|
| qa_discoverA | Fetches the OpenAPI/Swagger document of every configured service and reports the testable surface: endpoint count per service, how many assertions would be executed, which operations are skipped by the safety policy (and why), and which services could not be reached. Runs no test and sends no request to the endpoints themselves. Use this first to check coverage before running anything. |
| qa_run_apiA | Generates deterministic tests from OpenAPI and executes them against stage: contract (status declared in the spec + response body matches its schema), authz (secured endpoint called without a token must answer 401/403), robustness (malformed required parameter must answer 400/404/422), and perf (policy.maxResponseMs). Any 5xx is an unconditional critical failure. IMPORTANT: while policy.readOnly is true, every mutating endpoint (POST/PUT/PATCH/DELETE) is skipped unless its path is listed in policy.allowedMutationPaths — call qa_discover to see exactly what was skipped. Returns a digest; the full run is stored under artifactsDir. |
| qa_run_flowsA | Executes the hand-written business scenarios in tests/flows/*.yaml sequentially (they share state, so never in parallel). Each flow chains calls across services with {{variable}} interpolation, capture, expectStatus/expectBody and waitMs for eventual consistency. This is the only place where destructive operations are allowed, because a human wrote the steps. One flow = one result: on failure you get the failing step name, the trace of successful steps and every captured variable. |
| qa_run_uiA | Two layers against the React frontend. mode=specs runs the fixed Playwright specs in tests/ui (skipped with a clear message if playwright.config.ts is missing). mode=crawl logs in with a role and BFS-crawls same-origin links, failing a route on navigation error, HTTP >= 400, console errors, failing XHRs or an effectively empty render, with a full-page screenshot for every failure. If the login itself fails the crawl stops immediately with one critical result. mode=both runs the two in order. |
| qa_run_allA | One complete pass: discovery, generated API tests, YAML flows, Playwright specs and the frontend crawl — then an automatic comparison against the previous stored run. Returns the digest plus the diff buckets, of which |
| qa_reportA | Reads the full detail of a stored run with filters, for drilling into what a run digest truncated. Filter by status, severity, suite or service. Omit runId to read the most recent run. |
| qa_diffA | Compares two stored runs by stable test id and splits the delta into regressions (passed before, fails now — the release blocker), fixed, newFailures (test did not exist in the baseline), stillFailing and removed (endpoint or page gone). Defaults to comparing the latest run against the most recent earlier run that covered the same suites. |
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 7 tools
Each tool targets a distinct task: discovery, API tests, UI tests, flow tests, combined run, report reading, and diffing. There is no overlap in their purposes, and descriptions clearly delineate their roles.
All tools use a consistent qa_ prefix followed by a clear verb (discover, run_flows, run_api, run_ui, run_all, report, diff). The pattern is uniform and predictable, making it easy to infer tool functions from names.
Seven tools is well within the ideal range for a QA-focused server. Each tool covers a necessary step in the workflow without redundancy or bloat, making the set tightly scoped.
The tool surface covers the full QA lifecycle: discovering testable surface (qa_discover), executing different test types (flows, API, UI), running all together (qa_run_all), and then analyzing results via qa_report and qa_diff. There are no obvious dead ends or missing operations for the server's purpose.