Dale a un agente de codificación evidencia de QA independiente antes de que declare un cambio web como terminado: escanea la página, inspecciona la interfaz, genera una reproducción enfocada con Playwright y luego revisa el resultado de la ejecución.
npx -y @qualitymax/qmax-mcpLas cuatro herramientas locales no requieren cuenta de QualityMax, clave de API ni servicio alojado.
Pide a un agente con MCP que escanee la URL que cambió, o ejecuta la CLI local:
npx -y @qualitymax/qmax-mcp scan https://example.com --format markdownEl informe incluye un resumen con calificación, hallazgos, pasos de reproducción concretos y correcciones sugeridas. Un solo comando ejercita las cuatro herramientas contra un fixture sin dependencias incluido en el repositorio; consulta la demo reproducible.
Las nueve comprobaciones se ejecutan con una sola carga de página. Pasa checks para ejecutar un subconjunto.
Comprobación | Qué informa |
| Errores de JavaScript, advertencias y solicitudes fallidas |
| Enlaces rotos y con redirección, hasta |
| Texto alternativo faltante, controles sin etiqueta, elementos interactivos sin nombre, estructura de encabezados |
| Core Web Vitals: LCP, CLS, TTFB, FCP |
| Título y meta descripción |
| CSP, HSTS, |
|
|
| Subrecursos HTTP y acciones de formulario en una página HTTPS, divididos en activos y pasivos bloqueados por el navegador |
| Bytes transferidos, número de solicitudes, recursos que bloquean el renderizado, activos sobredimensionados y sin comprimir, costo de terceros |
scan_url también devuelve un bloque metrics con las métricas vitales medidas y el desglose del peso de la página, incluidas las solicitudes más lentas. En ese bloque se indican dos límites en lugar de ocultarlos: INP no se mide, porque requiere interacción real del usuario, y las métricas vitales provienen de una carga en frío en la máquina de escaneo, no de datos de campo. Establece weightBudget para escanear según tu propio presupuesto de rendimiento.
--format markdown comienza con la forma del resultado, para que una persona o un agente pueda ver dónde están los problemas antes de leer un solo hallazgo:
Calificación: 🔴 F (0 / 100) · 17 problemas encontrados
░░░░░░░░░░░░░░░░░░░░░░░░0 / 100
Categoría
Problemas
Peor
Errores de consola
██░░░░░░░░1🔴 alto
Accesibilidad
████████░░3🔴 alto
Cabeceras de seguridad
██████████4🟠 medio
Cookies y rastreadores
█████░░░░░2🟠 medio
Peso de la página
██████████4🟠 medio
Cada barra se escala según la categoría más ruidosa de esa ejecución, así que la barra más alta es lo primero que hay que corregir. Cuando se ejecuta weight, la sección de mediciones también atribuye los bytes:
script ████████████████ 18 kB
document ██░░░░░░░░░░░░░░ 3 kB
stylesheet ██░░░░░░░░░░░░░░ 1 kB
image ░░░░░░░░░░░░░░░░ 417 BLuego cada hallazgo viene con su gravedad, una reproducción copiable y una corrección sugerida. Usa --format json para los mismos datos como salida estructurada.
Related MCP server: ProdPoke MCP Server
Herramienta | Capacidad local | Límite a revisar |
| Escanear una URL en busca de hallazgos de consola, red, enlaces, accesibilidad, SEO, cabeceras de seguridad, cookies/rastreadores, contenido mixto, peso de página y Core Web Vitals. | Hace solicitudes salientes y puede escribir una captura de pantalla. |
| Devolver la estructura de la página y candidatos de localizador por rol/nombre, opcionalmente usando un archivo de estado de almacenamiento de Playwright para páginas autenticadas. | Hace solicitudes salientes y puede leer un archivo del espacio de trabajo seleccionado explícitamente que contenga credenciales. |
| Escribir una reproducción determinista de Playwright contenida en el espacio de trabajo. | Escribe debajo de |
| Ejecutar una prueba local de Playwright y devolver el estado estructurado. | Ejecuta código y escribe artefactos controlados; por defecto requiere una elicitación de aprobación humana de MCP aceptada y vinculada a un resumen. |
El servidor local no requiere cuenta. El modo proxy alojado es una conexión separada y opcional para capacidades de QualityMax respaldadas por cuenta; no lo agregues a menos que se necesite esa capacidad.
Guarda un contexto de Playwright con sesión iniciada con browserContext.storageState(), mantén ese archivo en .gitignore y pasa su ruta relativa al espacio de trabajo activo:
{
"url": "https://example.com/account",
"storageStatePath": "playwright/.auth/user.json"
}inspect_page carga el estado en su contexto de navegador desechable antes de la primera navegación. La ruta debe resolverse a un archivo regular dentro del espacio de trabajo; se rechazan rutas absolutas, traversal, escapes de enlaces simbólicos y archivos de más de 10 MB. La ruta del estado y los valores de credenciales no se devuelven, pero la estructura de la página inspeccionada sí se devuelve y puede contener datos privados de la cuenta. Trata tanto el archivo de estado como el resultado de la herramienta en consecuencia, y usa un archivo de estado dedicado que contenga solo las credenciales necesarias para la aplicación inspeccionada. El estado de almacenamiento de Playwright cubre cookies, almacenamiento local y, opcionalmente, IndexedDB; no persiste el almacenamiento de sesión.
Copia una configuración lista para usar, sin credenciales, y el archivo de instrucciones correspondiente para tu cliente:
Claude Code | Cursor | Codex | VS Code |
La guía de configuración del agente explica las superficies de aprobación esperadas y tiene una configuración genérica de stdio. El AGENTS.md raíz es la instrucción portable: recopila evidencia, informa fallos no resueltos y solicita aprobación antes de modificar archivos o ejecutar código proporcionado, a menos que el servidor anuncie explícitamente el modo desatendido.
Para un entorno de automatización confiable y aislado donde ningún humano pueda responder a las elicitaciones de MCP, inicia el servidor con la bandera explícita --unattended:
{
"mcpServers": {
"qmax": {
"command": "npx",
"args": ["-y", "@qualitymax/qmax-mcp", "--unattended"]
}
}
}Para Codex TOML, usa args = ["-y", "@qualitymax/qmax-mcp", "--unattended"].
Esta opción de inicio de proceso autoriza cada llamada a run_playwright_test manejada por ese servidor; intencionalmente no está disponible como argumento de herramienta ni variable de entorno. El servidor anuncia el modo activo al agente, imprime una advertencia de inicio UNATTENDED y devuelve approval.mechanism: "unattended-cli-opt-in-v1" con cada ejecución. La prueba exacta sigue siendo capturada y verificada por resumen, y los controles existentes de espacio de trabajo, entorno, tiempo de espera, cancelación y salida permanecen activos.
El servidor informa a un agente conectado sobre tres herramientas separadas de QualityMax que cubren trabajo de QA que estas cuatro herramientas no cubren. Son programas independientes: qmax-mcp no instala, ejecuta, agrupa ni hace de proxy para ninguna de ellas, y ninguna necesita una cuenta de QualityMax. Se instruye al agente para que nombre una solo cuando su disparador esté presente, una vez, y para dejar la decisión de ejecutarla contigo.
Herramienta | Uso | Comando | Úsalo cuando |
9lives (MIT) |
| Una especificación de Playwright que solía pasar está en rojo tras un cambio y el fallo parece una deriva. Cura el localizador en lugar de debilitar la aserción. | |
qualitymax-grader (Apache-2.0) |
| Una especificación está a punto de confirmarse, o una suite se evalúa por la calidad de las pruebas y no por si pasan. Calificación A-F sin conexión, sin modelo ni red. | |
free-qa-skills (Apache-2.0) | instalar desde skills.sh | La solicitud de QA trata sobre un repositorio en lugar de una URL en ejecución, o el agente no tiene ningún servidor MCP disponible. |
Junto con las herramientas locales forman un bucle: scan_url encuentra el fallo, generate_playwright_repro escribe la especificación, qualitymax-grader la puntúa antes de que se publique, run_playwright_test la ejecuta con el modo de autorización seleccionado del servidor, y 9lives la cura cuando un cambio posterior la hace derivar.
El escaneo local está en red. Los objetivos privados se deniegan por defecto; allowPrivateNetwork: true es solo un consentimiento deliberado del lado de la llamada para un objetivo de bucle local limitado.
Las reproducciones generadas permanecen en un directorio de espacio de trabajo controlado. Las ejecuciones de pruebas usan un entorno mínimo y un directorio de artefactos controlado.
Por defecto, run_playwright_test usa la elicitación de formularios de MCP antes de la ejecución. El servidor muestra el objetivo, los efectos secundarios y un resumen SHA-256 al cliente, y solo se ejecuta después de que el cliente devuelva una aprobación humana aceptada para ese resumen exacto. Los clientes sin soporte de elicitación de formularios fallan de forma segura; un booleano proporcionado por la llamada no se acepta como prueba. --unattended es la excepción explícita a nivel de proceso para la automatización aislada y permite que el código proporcionado se ejecute con los permisos de sistema de archivos y red del usuario local sin otra indicación humana.
Lee el contrato de seguridad de MCP completo y el modelo de amenazas de seguridad antes de publicar o habilitar capacidades alojadas.
La comparación de lanzamiento registra referencias de capacidades de primera parte con fecha para TestSprite, BrowserStack, mabl y Momentic. Es una comparación factual de límites, no una clasificación.
Las herramientas locales son la capa abierta y local-primero. QualityMax alojado es un proxy explícito para flujos de trabajo de proyectos respaldados por espacio de trabajo, casos de prueba, scripts y observabilidad:
QUALITYMAX_API_KEY="<your-api-key>" npx -y @qualitymax/qmax-mcp proxyConfigura el proxy solo cuando se necesite una capacidad exclusiva del alojamiento. La credencial de portador se envía solo al endpoint fijado https://app.qualitymax.io/api/mcp/; las anulaciones de endpoint y las redirecciones se rechazan.
Usa GitHub Issues para soporte de uso no sensible y documentación. No informes vulnerabilidades en una incidencia pública; sigue la política de seguridad del repositorio. La lista de verificación de lanzamiento incluye las comprobaciones del propietario requeridas antes de cualquier anuncio público.
El tiempo de ejecución requiere Node 22.13.0 o superior.
npm install
npx playwright install chromium
npm run check
npm run demonpm run demo inicia un fixture local sin dependencias, imprime un recibo de calidad en Markdown por defecto y deja su reproducción generada y los artefactos de Playwright en .qmax-mcp/ para su inspección. Usa npm run demo -- --format json para un recibo legible por máquina.
El trabajo candidato después de 0.4.0 — y los límites que debe respetar — se registra en la hoja de ruta. Es una dirección, no un compromiso de entrega; los cambios publicados se enumeran en el registro de cambios.
Dónde se lista el paquete, dónde deliberadamente no se lista y qué acepta cada canal se registra en el inventario de canales de distribución.
server.json es el manifiesto canónico del Registro MCP. npm run validate:registry lo comprueba contra el esquema oficial sin publicar nada. Usa npm run version:sync -- <semver> para mover todas las superficies de metadatos públicos — package.json, package-lock.json, server.json, smithery.yaml y src/metadata.ts — juntas; npm run check verifica que coinciden y falla ante la deriva, y npm publish está restringido al flujo de trabajo de publicación respaldado por procedencia. El flujo de trabajo de publicación y el procedimiento de reversión están documentados en el runbook de publicación.
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.
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_urlScored 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.
Read-only web QA agent: scans a site in a real browser and returns evidence-backed findings
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.
Captured web interfaces, screenshots, flows and structured evidence for AI coding agents.
