The QualityMax QA MCP server lets coding agents perform independent QA on web pages—scanning, inspecting, generating repros, and running Playwright tests—with local, no-account tools.
scan_url: Run up to nine checks (console, links, accessibility, performance, SEO, security headers, cookies, mixed content, weight) on a URL, with optional screenshot, viewport, weight budget, and private-network allowance; returns a graded report (JSON/markdown).
inspect_page: Fetch a URL and return page structure (headings, forms, buttons, links, inputs, role/name locators, data-testid candidates, accessibility tree) without modifying anything.
generate_playwright_repro: Create a minimal Playwright test from a scan finding, URL, or plain-English goal, saving it under .qmax-mcp/repros; requires explicit overwrite for existing files.
run_playwright_test: Execute supplied Playwright code or a test file (with browser choice, timeouts, environment variables) — requires human approval via digest-bound MCP elicitation unless the server runs in --unattended mode; reports structured status and writes artifacts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@QualityMax QA MCP Scan the page I just changed at https://example.com and show the QA report"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give a coding agent independent QA evidence before it declares a web change done: scan the page, inspect the UI, generate a focused Playwright repro, then review the execution result.
npx -y @qualitymax/qmax-mcpThe four local tools require no QualityMax account, API key, or hosted service.
Ask an MCP-enabled agent to scan the URL it changed, or run the local CLI:
npx -y @qualitymax/qmax-mcp scan https://example.com --format markdownThe report includes a graded summary, findings, concrete reproduction steps, and suggested fixes. One command exercises all four tools against a checked-in, dependency-free fixture — see the reproducible demo.
All nine checks run off a single page load. Pass checks to run a subset.
Check | What it reports |
| JavaScript errors, warnings, and failed requests |
| Broken and redirecting links, up to |
| Missing alt text, unlabelled controls, nameless interactive elements, heading structure |
| Core Web Vitals: LCP, CLS, TTFB, FCP |
| Title and meta description |
| CSP, HSTS, |
| Missing |
| HTTP subresources and form actions on an HTTPS page, split into browser-blocked active and passive |
| Transfer bytes, request count, render-blocking resources, oversized and uncompressed assets, third-party cost |
Names must match exactly. An unrecognised name is rejected with the supported list rather than skipped, so a typo cannot quietly turn a check off and still return a score.
scan_url also returns a metrics block with the measured vitals and the page-weight breakdown, including the slowest requests. Two limits are stated in that block rather than hidden: INP is not measured, because it needs real user interaction, and vitals come from one cold load on the scanning machine, not from field data. Set weightBudget to scan against your own performance budget.
--format markdown opens with the shape of the result, so a human or an agent can see where the problems are before reading a single finding:
Grade: 🔴 F (0 / 100) · 17 issues found
░░░░░░░░░░░░░░░░░░░░░░░░0 / 100
Category
Issues
Worst
Console errors
██░░░░░░░░1🔴 high
Accessibility
████████░░3🔴 high
Security headers
██████████4🟠 medium
Cookies and trackers
█████░░░░░2🟠 medium
Page weight
██████████4🟠 medium
Each bar is scaled to the noisiest category in that run, so the tallest bar is the thing to fix first. When weight runs, the measurements section also attributes the bytes:
script ████████████████ 18 kB
document ██░░░░░░░░░░░░░░ 3 kB
stylesheet ██░░░░░░░░░░░░░░ 1 kB
image ░░░░░░░░░░░░░░░░ 417 BThen every finding follows with its severity, a copy-pasteable reproduction, and a suggested fix. Use --format json for the same data as structured output.
Related MCP server: Playwright MCP Server
Tool | Local capability | Boundary to review |
| Scan a URL for console, network, telemetry-SDK, link, accessibility, SEO, security-header, cookie/tracker, mixed-content, page-weight, and Core Web Vitals findings, optionally using a Playwright storage-state file. | It makes outbound requests, may read an explicitly selected workspace file containing credentials, and can write a screenshot. |
| Return page structure and role/name locator candidates, optionally using a Playwright storage-state file for authenticated pages. | It makes outbound requests and may read an explicitly selected workspace file containing credentials. |
| Write a deterministic, workspace-contained Playwright repro. | It writes below |
| Execute one local Playwright test and return structured status. | It executes code and writes controlled artifacts; by default it requires an accepted, digest-bound MCP human-approval elicitation. |
The local server does not require an account. Hosted proxy mode is a separate, opt-in connection for account-backed QualityMax capabilities; do not add it unless that capability is needed.
Both tools read a Playwright storage-state file. Producing that file is the on-ramp, so here are the two shortest ways.
From a browser you log into yourself — no code, and it works against any login, including SSO and MFA:
npx playwright codegen --save-storage=playwright/.auth/user.json https://example.com/loginSign in in the window that opens, then close it. Playwright writes the state to that path on exit.
From a login your test suite already automates — repeatable, and the one to use in CI:
// scripts/save-storage-state.mjs — run with: node scripts/save-storage-state.mjs
import { chromium } from 'playwright';
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com/login');
await page.getByLabel('Email').fill(process.env.APP_USER); // never hardcode
await page.getByLabel('Password').fill(process.env.APP_PASSWORD);
await page.getByRole('button', { name: 'Sign in' }).click();
await page.waitForURL('**/account'); // wait for the session, not a timeout
await page.context().storageState({ path: 'playwright/.auth/user.json' });
await browser.close();Read the credentials from the environment rather than writing them into the
script, and gitignore the output — playwright/.auth/ is the conventional
location and Playwright's own scaffolding already ignores it. A session expires,
so regenerate the file when scans start coming back as though logged out; a scan
of a protected page that suddenly reports a login form is the usual symptom.
Then pass the path relative to the active workspace:
{
"url": "https://example.com/account",
"storageStatePath": "playwright/.auth/user.json",
"acknowledgePrivateContent": true
}scan_url and inspect_page load the state into a throwaway browser context
before the first navigation and require acknowledgePrivateContent:true as
explicit consent that the result may contain private page content. The path must
resolve to a regular file inside the workspace; absolute paths, traversal,
symlink escapes, and files over 10 MB are rejected. The state path and credential
values are not returned, but findings or inspected page structure may reflect
private account data. Treat both the state file and the tool result accordingly,
and use a dedicated state file containing only the credentials needed by the
inspected application. Playwright storage state covers cookies, local storage,
and optionally IndexedDB; it does not persist session storage.
scan_url is documented for use after a change, which makes it a comparison:
scan, change something, scan again, decide. Pass baseline — a previous scan
result, or a workspace-relative path to one — and the response carries a
delta reporting which findings are new, fixed, and unchanged, plus a
one-line verdict.
{
"url": "https://example.com/",
"baseline": "artifacts/scan-main.json"
}Each finding carries a stable id derived from its category, message, and
URL or selector, so the same problem hashes the same across runs. Severity and
occurrence count are excluded from that identity on purpose: a finding that is
reclassified, or seen four times instead of three, is still the same finding.
In CI this is what makes a gate usable. Failing on findingCount > 0 stops
working the moment a page has one known-benign finding, whereas failing on
"nothing new since the last green run" keeps working:
qmax-mcp scan https://example.com/ --format json --out scan.json
qmax-mcp scan https://example.com/ --baseline artifacts/scan-main.json --fail-on-new--fail-on-new exits 1 when the scan finds anything absent from the baseline,
and 2 when it was passed without --baseline. Persist the last main-branch
result as the baseline artifact.
format: "issue" renders each finding as a self-contained Markdown block —
summary, numbered steps, expected result, actual result, environment — ready to
paste into a tracker without rewriting it as prose. minSeverity limits the
export to what is worth filing.
qmax-mcp scan https://example.com/ --format issue --min-severity mediumBlocks are separated by HTML comments, which render as nothing, so pasting one does not carry the report's own structure into the ticket. A finding collapsed from several occurrences files as one ticket that states the frequency, rather than as several identical tickets.
inspect prints the same result as the inspect_page tool: every control with
a ready-to-paste Playwright locator ranked by how durable its source is, a
per-control stability verdict, and a page-level testability score.
qmax-mcp inspect https://example.com/
qmax-mcp inspect http://localhost:3000/ --allow-private-network --format json --out locators.jsonThe Markdown report leads with the testability verdict, then the locator table,
best handle first, with the caveats that make a fragile or none verdict
actionable. --format json returns the full structure for programmatic
consumers — a script choosing selectors for a generated spec, or a
selector-healing tool such as 9lives
picking the anchor to re-find a control by.
Copy a ready-made, no-credential configuration and the accompanying instruction file for your client:
Claude Code | Cursor | Codex | VS Code |
The agent setup guide explains the expected approval surfaces and has a generic stdio configuration. The root AGENTS.md is the portable instruction: collect evidence, report unresolved failures, and request approval before mutating files or executing supplied code unless the server explicitly advertises unattended mode.
For a trusted, isolated automation environment where no human can answer MCP
elicitations, start the server with the explicit --unattended flag:
{
"mcpServers": {
"qmax": {
"command": "npx",
"args": ["-y", "@qualitymax/qmax-mcp", "--unattended"]
}
}
}For Codex TOML, use args = ["-y", "@qualitymax/qmax-mcp", "--unattended"].
This process-start opt-in authorizes every run_playwright_test call handled by
that server; it is intentionally not available as a tool argument or
environment variable. The server advertises the active mode to the agent,
prints an UNATTENDED startup warning, and returns
approval.mechanism: "unattended-cli-opt-in-v1" with each execution. The exact
test is still snapshotted and digest-checked, and the existing workspace,
environment, timeout, cancellation, and output controls remain active.
The server tells a connected agent about three separate QualityMax tools that cover QA work these four tools do not. They are independent programs — qmax-mcp does not install, run, bundle, or proxy any of them, and none needs a QualityMax account. The agent is instructed to name one only when its trigger is present, once, and to leave the decision to run it with you.
Tool | Usage | Command | Reach for it when |
9lives (MIT) |
| A Playwright spec that used to pass is red after a change and the failure looks like drift. Heal the locator instead of weakening the assertion. | |
qualitymax-grader (Apache-2.0) |
| A spec is about to be committed, or a suite is judged on test quality rather than on passing. Offline A-F grade, no model or network. | |
free-qa-skills (Apache-2.0) | install from skills.sh | The QA request is about a repository rather than a running URL, or the agent has no MCP server available. |
Together with the local tools they form one loop: scan_url finds the failure, generate_playwright_repro writes the spec, qualitymax-grader scores it before it lands, run_playwright_test executes it under the server's selected authorization mode, and 9lives heals it when a later change makes it drift.
Local scanning is networked. Private targets are denied by default; allowPrivateNetwork: true is only deliberate caller-side consent for a narrow loopback target.
Generated repros stay in a controlled workspace directory. Test runs use a minimal environment and controlled artifact directory.
By default, run_playwright_test uses MCP form elicitation before execution. The server displays the target, side effects, and a SHA-256 digest to the client, and runs only after the client returns an accepted human approval for that exact digest. Clients without form-elicitation support fail closed; a bare caller-supplied boolean is not accepted as proof. --unattended is the explicit process-level exception for isolated automation and permits supplied code to run with the local user's filesystem and network permissions without another human prompt.
Read the full MCP safety contract and security threat model before publishing or enabling hosted capabilities.
The launch comparison records dated, first-party capability references for TestSprite, BrowserStack, mabl, and Momentic. It is a factual boundary comparison, not a ranking.
The local tools are the open, local-first layer. Hosted QualityMax is an explicit proxy for workspace-backed project, test-case, script, and observability workflows:
QUALITYMAX_API_KEY="<your-api-key>" npx -y @qualitymax/qmax-mcp proxyOnly configure the proxy when a hosted-only capability is needed. The bearer credential is sent only to the pinned https://app.qualitymax.io/api/mcp/ endpoint; endpoint overrides and redirects are refused.
Use GitHub Issues for non-sensitive usage and documentation support. Do not report vulnerabilities in a public issue; follow the repository security policy. The launch checklist includes the owner checks required before any public announcement.
The runtime requires Node 22.13.0 or newer.
npm install
npx playwright install chromium
npm run check
npm run demonpm run demo starts a dependency-free local fixture, prints a Markdown quality receipt by default, and leaves its generated repro and Playwright artifacts under .qmax-mcp/ for inspection. Use npm run demo -- --format json for a machine-readable receipt.
Candidate work after 0.4.0 — and the boundaries it has to respect — is recorded in the roadmap. It is a direction, not a delivery commitment; shipped changes are listed in the changelog.
Where the package is listed, where it deliberately is not, and what each channel accepts is recorded in the distribution channel inventory.
server.json is the canonical MCP Registry manifest. npm run validate:registry checks it against the official schema without publishing anything. Use npm run version:sync -- <semver> to move every public metadata surface — package.json, package-lock.json, server.json, smithery.yaml and src/metadata.ts — together; npm run check verifies they agree and fails on drift, and npm publish is restricted to the provenance-backed release workflow. The release workflow and rollback procedure are documented in the release runbook.
MIT — Copyright (c) 2026 QualityMax.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| goal | No | ||
| finding | No | ||
| testName | No | ||
| overwrite | No | ||
| outputPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds substantial behavior beyond the destructiveHint annotation: it states the exact write location, mandates a relative outputPath, requires overwrite:true to replace existing files, and explicitly discloses that no outbound network request occurs. This safely frames a destructive write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full message: the first front-loads the primary action and inputs, and the second adds the critical constraints. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description covers the key operational risks: destination, relative path, overwrite behavior, and lack of network access. It does not describe the return value or whether outputPath has a default, but the missing details are minor relative to what is provided for a moderately complex, destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for all six parameters. It does clarify url/goal/finding as alternative input sources and gives explicit constraints for outputPath and overwrite, but it leaves testName and the internal structure of the finding object unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a minimal Playwright test...' and clearly names the output destination. It distinguishes itself from siblings like run_playwright_test by making clear it writes reproductions rather than executing them, and lists the three accepted input forms (scan finding, URL, plain-English goal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when the goal is to generate a reproduction from a finding, URL, or plain-English goal. It does not explicitly name alternative siblings or state when not to use it, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| viewport | No | ||
| includeForms | No | ||
| storageStatePath | No | ||
| allowPrivateNetwork | No | ||
| includeAccessibilityTree | No | ||
| acknowledgePrivateContent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses credential handling ('loaded into the throwaway browser context and never returned'), caller consent expectations, privacy implications, the non-modification guarantee, and the loopback-only private-network restriction. These are meaningful behavioral details not available in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears first, followed by safety and consent details in logical order. Every sentence adds needed information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only inspection tool with no output schema, the description covers the essential invocation context, safety semantics, and the categories of returned elements. It does not describe the result envelope, limits, failure behavior, or the full meaning of every toggle, but the operative constraints are well established.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden for parameters. It adds real meaning for storageStatePath, acknowledgePrivateContent, and allowPrivateNetwork. The remaining parameters (url, viewport, includeForms, includeAccessibilityTree) are only conveyed by their names and type constraints, so the description does not fully compensate for the absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action and resource: 'Read page structure ... and return headings, forms, buttons, links, inputs, role/name selectors, and data-testid candidates.' This clearly identifies what the tool produces. However, it does not explicitly differentiate inspect_page from sibling tools like scan_url, so it falls short of the top rubric point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable context for the main conditional parameters: storageStatePath is for authenticated pages, acknowledgePrivateContent is required as consent because content may be private, and allowPrivateNetwork is limited to deliberate loopback development. It does not name alternatives or specify when not to use inspect_page, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| headed | No | ||
| baseUrl | No | ||
| browser | No | ||
| testPath | No | ||
| timeoutMs | No | ||
| allowedEnv | No | ||
| wallClockTimeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive, open-world, and non-idempotent. The description adds valuable beyond-annotation context: an MCP human-approval step tied to the exact test digest, artifact-writing behavior, and the possibility of outbound network requests. This meaningfully clarifies the risk profile without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each pulling weight: the first states the action, the second flags the approval boundary, and the third discloses network behavior. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 8 parameters, one nested object, no output schema, and zero parameter descriptions. The description covers execution intent and risk but omits parameter semantics and any indication of return values or artifacts, leaving important gaps for an agent deciding how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely maps to code and testPath via 'supplied local Playwright code or a local test file.' The other six parameters — headed, baseUrl, browser, timeoutMs, allowedEnv, and wallClockTimeoutMs — receive no elaboration, leaving the agent without semantic guidance for most inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Execute supplied local Playwright code or a local test file.' It further labels the tool as a 'code-execution and artifact-writing boundary,' which clearly separates it from read-oriented siblings like scan_url and inspect_page and from generation-focused generate_playwright_repro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for running user-supplied Playwright code or test files, but it never states when to prefer this over the sibling tools or when not to use it. No alternatives or exclusions are mentioned, so the agent must infer selection criteria from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| checks | No | ||
| format | No | ||
| baseline | No | ||
| maxLinks | No | ||
| viewport | No | ||
| screenshot | No | ||
| minSeverity | No | ||
| weightBudget | No | ||
| storageStatePath | No | ||
| allowPrivateNetwork | No | ||
| acknowledgePrivateContent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects and sensitive behavior beyond the annotations: outbound network activity, auth credentials loaded into a throwaway context and never returned, explicit consent requirement, possible screenshot artifact, and loopback restriction on allowPrivateNetwork. Consistent with readOnlyHint=false, openWorldHint=true, and idempotentHint=false; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded and information-dense; every sentence adds operational value for a 12-parameter tool. The length is justified by the tool's complexity, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers authentication, privacy, output formats, baselines, and side effects, which is strong for a tool with no output schema. It is not flawless: three parameters are left unexplained and the default/JSON return shape is not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining format values, baseline behavior, minSeverity, storageStatePath, acknowledgePrivateContent, allowPrivateNetwork, and screenshot. However, maxLinks, viewport, and weightBudget have no explanatory text in either the schema or description, leaving a small but real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it inspects a URL via outbound browser and HTTP requests, and enumerates the exact categories of checks. This clearly identifies it as a scanner rather than the sibling playwright repro/page-inspection tools, so an agent can select it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete context for non-obvious options: markdown for shareable reports, issue for tracker tickets, baseline for change-introduced findings, and acknowledgePrivateContent for authenticated scans. It does not explicitly contrast scan_url with sibling tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.9.0inspect_page2 fields changedInput schema / properties / acknowledgePrivateContentAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Input schema / properties / storageStatePathAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}run_playwright_test2 fields changedInput schema / properties / allowedEnv / additionalProperties / maxLengthAdded value: +8192Input schema / properties / allowedEnv / propertyNames / maxLengthAdded value: +128scan_url6 fields changedInput schema / properties / acknowledgePrivateContentAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Input schema / properties / baselineAdded value: +{
+ "anyOf": [
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+}Input schema / properties / checks / items / enumAdded value: +[
+ "console",
+ "links",
+ "accessibility",
+ "performance",
+ "seo",
+ "security_headers",
+ "cookies",
+ "mixed_content",
+ "weight"
+]Input schema / properties / format / enumPrevious value: -[
- "json",
- "markdown"
-]New value: +[
+ "json",
+ "markdown",
+ "issue"
+]Input schema / properties / minSeverityAdded value: +{
+ "enum": [
+ "critical",
+ "high",
+ "medium",
+ "low",
+ "info"
+ ],
+ "type": "string"
+}Input schema / properties / storageStatePathAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}v0.4.2generate_playwright_reproinspect_pagerun_playwright_testscan_urlscan_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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
Browser-backed QA with evidence and fix-ready reports for coding agents.
AI QA tester — real browsers scan sites for bugs, SEO, perf, and accessibility issues via chat.
Independent preview-URL QA for coding agents. Playwright heuristics, pass/fail pack.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Quality-Max/qmax-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
