QualityMax QA MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QUALITYMAX_API_KEY | No | API key for hosted proxy mode. Only needed when running the proxy. |
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 |
|---|---|
| scan_urlA | Inspect a URL with outbound browser and HTTP network requests for console errors, links, accessibility, Core Web Vitals, SEO, security headers, cookie and tracker privacy, mixed content, and page weight. storageStatePath may name a workspace-relative Playwright storage-state file so the checks can run on an authenticated page; its credentials are loaded into the throwaway browser context and never returned. Because returned findings may reflect private content, authenticated scans also require acknowledgePrivateContent:true as explicit caller consent. This may write a local screenshot artifact when screenshot:true. Set format:"markdown" for a shareable graded report, or format:"issue" to render each finding as a self-contained ticket block (summary, steps, expected, actual, environment) ready to paste into a tracker; minSeverity filters that export. baseline takes a previous scan result, or a workspace-relative path to one, and adds a delta reporting which findings are new, fixed, and unchanged — use it to answer whether a change introduced anything rather than comparing two results by eye. allowPrivateNetwork:true is limited to deliberate loopback development targets. |
| inspect_pageA | Read page structure through outbound browser network requests and return headings, forms, buttons, links, inputs, role/name selectors, and data-testid candidates. storageStatePath may name a workspace-relative Playwright storage-state file for authenticated pages; its credentials are loaded into the throwaway browser context and never returned. Because returned page content may be private, authenticated inspection also requires acknowledgePrivateContent:true as explicit caller consent. Does not intentionally modify the target or local filesystem. allowPrivateNetwork:true is limited to deliberate loopback development targets. |
| generate_playwright_reproA | Generate a minimal Playwright test from a scan finding, URL, or plain-English goal and write it below the approved workspace directory .qmax-mcp/repros. outputPath must be relative; existing files require overwrite:true after review. No outbound network request is made by generation. |
| run_playwright_testA | Execute supplied local Playwright code or a local test file. This is a code-execution and artifact-writing boundary: qmax-mcp first requires an MCP human-approval elicitation bound to the exact test digest. The runner may make outbound network requests requested by the test. |
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 4 tools
scan_url and inspect_page both involve browser access but are clearly differentiated: scan_url is a full quality audit with findings and reports, while inspect_page returns structural selectors and page elements. generate_playwright_repro creates tests and run_playwright_test executes them, so overall tool boundaries are clear, though one could initially confuse scan_url with inspect_page.
All tools consistently use a verb_object snake_case pattern: scan_url, inspect_page, generate_playwright_repro, run_playwright_test. There are no vague generic verbs or mixed conventions, making the intent of each tool predictable from its name.
Four tools is well within the ideal 3-15 range and each tool represents a distinct high-level QA workflow: auditing a URL, inspecting page structure, generating a reproduction, and executing a test. The count feels appropriately scoped rather than thin or bloated.
The core QA workflow is covered: scan a URL for issues, inspect page structure, generate a Playwright reproduction, and run Playwright tests. Minor gaps exist such as managing or listing generated repro artifacts, but these do not create dead ends for the server's apparent purpose.