Reported issues for QualityMax QA MCP
Pod holds 16 of 17 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to QualityMax QA MCP.
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 · 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 · 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 · 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 <img> or <svg> inside a <div class="cursor-pointer"> 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 · 2026-08-25 · closed · outside contributor · 1 comment
scan_url: support storageStatePath so the nine checks can run on authenticated pages
Summary
inspect_page gained storageStatePath (I believe via #53), but scan_url has no equivalent, so none of the nine checks can run behind a login. For an app where almost everything meaningful is authenticated, the scan is limited to the login page.
Why it matters here
The product I'm testing has one unauthenticated page (login). Everything else — the main dashboard, media library, session list, messaging — is behind auth. So scan_url can never see the accessibility, console-e
Read the thread · 2026-08-25 · closed · outside contributor · 1 comment
inspect_page returns an entirely empty snapshot for client-rendered apps, with no way to tell that from a page with no controls
Summary
On a client-rendered app (Next.js App Router in my case), inspect_page returns the page title but empty headings, interactive, forms, and accessibilityTree — even on pages that definitely have a form and buttons once hydrated. There is no field in the response distinguishing "this page genuinely has no controls" from "I snapshotted before the app rendered", so the result reads as authoritative when it isn't.
This matters because the stated purpose is to hand back real lo
Read the thread · 2026-08-25 · closed · outside contributor · 1 comment
Tools report clean/empty results for work that never ran (scan_url checks, inspect_page snapshot, finding selectors)
Three findings that share one shape: absence of evidence is presented as evidence of absence. A caller keyed on score, findingCount, or an empty interactive[] draws the opposite of the correct conclusion, and nothing in the response flags the ambiguity.
This is the group worth fixing first, because it's the only one that can make a passing result wrong.
All found in one evaluation session: qmax-mcp 0.5.0 via npx -y @qualitymax/qmax-mcp, stdio, local mode, no account; macOS, Node
Read the thread · 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 · 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 · 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:
{
"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 · 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 · 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: <Link> 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 · 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 <label> text (from #69)
Reporting a false-positive mode in the check I added in #69, found while using 0.6.0 on a real application. Filing it against my own contribution because it will otherwise cost other people time, and because the fix looks small.
## Symptom
The check flags clickable label text as a keyboard trap, even when the associated form control is perfectly reachable.
On a registration form, 0.6.0 reports three keyboard-unreachable controls. Only one is genuine:
- Hiermit a
Read the thread · 2026-08-26 · closed · outside contributor · 0 comments
Capability boundaries are invisible at the point of use: workspace specs, authenticated scans, and clickable-but-not-focusable elements
Three capability gaps. Each is defensible as scope — what costs time is that the boundary is only discoverable by reading dist/, comparing two tools' schemas, or knowing what the check can't see.
Environment for all three: qmax-mcp 0.5.0 via npx -y @qualitymax/qmax-mcp, stdio, local mode; macOS, Node 20; target is a Next.js App Router app on localhost.
1. run_playwright_test can't run a workspace's own spec files
The tool advertises "Execute supplied local Playwright code **or a
Read the thread · 2026-08-25 · closed · outside contributor · 0 comments
The remaining reports are on the project's issue tracker.