# QualityMax QA MCP MCP Server Local QA MCP: scan URLs, inspect pages, generate Playwright repros, and run tests. **Publisher claimed.** No tool list reported, and Pod has not connected to this server. ## Status Pod has not dialled QualityMax QA MCP yet, so everything on this page is what its publisher reported rather than what we observed. Registries describe servers; they do not connect to them. Until a check runs, treat the tool list below as a claim. ## Connect Published as `@qualitymax/qmax-mcp` on npm. Runs locally. ## Known issues **17 problems reported by people outside the maintainer team.** Issues filed by the project's own owners, members and collaborators are excluded — those are release checklists and internal refactors, not things that will go wrong for you. Showing 12. ### Most discussed ### Tracking: findings from an E2E test-authoring session (#77–#83) Umbrella for seven issues distilled from one real session of writing Playwright specs and pre-PR scans against a Next.js App Router application in a Docker E2E stack (same spirit as #65's evaluation batch). What worked and stays unchanged: inspect_page prevented guessed-selector failures twice; the clickable-but-not-focusable check (#62) caught a genuine keyboard-accessibility blocker; storageStatePath (#53/#61) and the unattended authorization model behaved as documented. The gaps, ordered by [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/84) · 2026-08-26 · closed · outside contributor · 2 comments ### Tracking: qmax-mcp fails open — several tools report success for work they didn't do (#58–#64 from one evaluation session) Umbrella for #58–#64, all found in a single evaluation session against one real app (Next.js App Router, local Docker stack, qmax-mcp 0.5.0). Filing this because the individual reports share a theme that is more actionable than any one of them: **in the cases where the tools cannot do their job, they tend to return something that looks like success.** I've left the detail in the child issues; this is the through-line and a suggested order of attack. --- ## Theme 1 — Results that look clean bu [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/65) · 2026-08-25 · closed · outside contributor · 1 comment ### Diagnostics: approval failures and inapplicable checks hide information the server already has Two cases where the server knows the answer and doesn't say it. Both cost real time; neither needs new capability, just reporting what's already known. Environment: qmax-mcp 0.5.0 via `npx -y @qualitymax/qmax-mcp`, stdio, local mode, default (gated) start; macOS, Node 20; non-interactive agent session with no human able to answer an elicitation. --- ## 1. `run_playwright_test` approval failure doesn't say which mode is active The entire error is: ``` Human approval for code execution was de [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/64) · 2026-08-25 · closed · outside contributor · 1 comment ### scan_url finding quality: non-unique selectors make duplicate findings unactionable, and HSTS is flagged on plain-HTTP targets Two small, unrelated-but-adjacent papercuts in `scan_url` output. Happy to split if you'd rather track them separately. ## 1. Findings use non-unique selectors A single scan returned two findings that are byte-identical apart from nothing at all: ```json { "severity": "medium", "category": "accessibility", "message": "Interactive element has no accessible name.", "selector": "a", "repro": "1. Open http://localhost:3000/login\n2. Inspect `a`\n3. Note: ..." } ``` ...twice. Both say `sele [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/63) · 2026-08-25 · closed · outside contributor · 1 comment ### accessibility check misses clickable-but-not-focusable elements (icon in a div), a common React pattern ## Summary The accessibility check reports *interactive* elements missing an accessible name. It therefore cannot see the most common React accessibility bug: a control implemented as a non-interactive element — typically an `` or `` inside a `
` with an `onClick` — which is unreachable by keyboard and not exposed to assistive technology at all. Because such an element isn't interactive as far as the DOM is concerned, there is nothing for the current check [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/62) · 2026-08-25 · closed · outside contributor · 1 comment ### Most recent ### scan_url: issue-ready per-finding export (summary / steps / expected / actual) for tracker filing ## What happened One scanning session produced findings that became six hand-written tracker tickets (a misconfigured-telemetry bug, an accessibility blocker, and several API-contract bugs found while investigating). Each ticket needed the same transformation: finding → one-line summary, numbered reproduction steps, expected result, actual result, environment note. scan_url findings already carry ~80% of this (`message`, `repro`, `suggestion`, `selector`/`url`, `severity`), but as scan-report f [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/83) · 2026-08-26 · closed · outside contributor · 0 comments ### storageStatePath exists, but producing the storage-state file is the remaining friction for authenticated scans ## What happened #53/#61 added `storageStatePath` to inspect_page and scan_url — the capability is there. In a real session covering an app with a login wall, every scan nevertheless stayed on the three public pages (login, password reset), because no Playwright storage-state file existed: the project's test helpers log in per-test and never persist state, and minting the file means writing and running a one-off setup script before the first authenticated scan can happen. The practical effect: [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/82) · 2026-08-26 · closed · outside contributor · 0 comments ### inspect_page: no testability verdict when a control has no stable handle; placeholder-derived names recommended without caveat ## What happened Two related cases from one session of writing Playwright specs against inspect_page output. **Case 1 — silent brittle fallback.** A password-reset form rendered two `input[type=password]` with no id, no name, and no label association. inspect_page reported them like this: ```json { "tag": "input", "role": "textbox", "name": "", "type": "password", "selector": "div > form > div > div:nth-of-type(1) > div:nth-of-type(2) > input", "testId": null } ``` No `recommendedLocat [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/81) · 2026-08-26 · closed · outside contributor · 0 comments ### scan_url: baseline/diff mode — report fixed/new/unchanged between two scans of the same URL ## What happened The workflow scan_url is documented for — "use after any UI or Docker config change so regressions surface before a PR is opened" — is inherently a *comparison*: scan, change something, scan again, decide. In a real session (a Docker env change that disabled misconfigured telemetry SDKs) that comparison was done by eyeballing two JSON blobs: 17 findings before, 2 after, and a human diffing messages by hand to confirm the 2 survivors were pre-existing rather than regressions. # [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/80) · 2026-08-26 · closed · outside contributor · 0 comments ### scan_url: Next.js RSC/prefetch ERR_ABORTED counted as medium findings — a clean App Router page caps at 80 ## What happened After fixing every real console/network problem on a Next.js App Router login page, the console-only scan still reported: ``` score: 80 medium network Request failed: net::ERR_ABORTED url: http://localhost:13001/login (x2) ``` These are the router's own doing: `` prefetches and RSC payload fetches that get superseded by navigation are deliberately aborted by the framework. They occur on essentially every App Router page, are invisible to users, and are not actiona [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/79) · 2026-08-26 · closed · outside contributor · 0 comments ### scan_url: one root cause yields six findings — identical messages repeated within and across categories ## What happened Scanning a Next.js App Router page (`checks: ["console", "accessibility", "security_headers"]`) returned 17 findings, of which 6 were a single root cause — a Sentry SDK initialized with a stub DSN, POSTing envelopes to an unreachable host. The same event was reported **three times as identical high-severity `console` findings and three more times as identical medium `network` findings**: ``` high console error: Failed to load resource: net::ERR_BLOCKED_BY_CLIENT.Inspector [Read the thread](https://github.com/Quality-Max/qmax-mcp/issues/77) · 2026-08-26 · closed · outside contributor · 0 comments ### Keyboard-reachability check false-positives on clickable