What can you do with this server?

Playwright Report MCP is a Model Context Protocol server that lets AI agents run Playwright tests and analyze results with structured, token-efficient output — without overwhelming context windows. * Run Playwright tests (run_tests) with options for spec, browser, tag, timeout, workers, retries, max failures, tracing, headless mode, snapshot updates, and synchronous or background execution. * Check background run status (get_run_status) with progress, elapsed time, exit code, and results.json metadata. * Retrieve failed tests (get_failed_tests) from the latest run, including error messages and attachment paths, without re-running tests. * Read attachment content (get_test_attachment) for any test by name, such as error-context (YAML accessibility tree snapshot), ai-diagnosis, page-html, or custom text logs. * List all tests (list_tests) with spec files and tags without executing them, optionally filtered by tag. * Support multiple worktrees/projects via an optional workingDirectory parameter, restricted by a configurable PW_ALLOWED_DIRS allowlist. * Optimize token usage by filtering to failed tests and reading only necessary attachments, vastly reducing context cost for AI analysis. * Integrate with any MCP-compatible client using stdio, supporting both modern and legacy MCP protocol versions.

How do I use playwright-report-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@playwright-report-mcp run tests and show failed results" 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.

playwright-report-mcp

by hubertgajewski

Overview Schema Related Servers Score Discussions

TypeScript

Local

Playwright Report MCP

An MCP (Model Context Protocol) server for running Playwright tests and reading structured results, failed test details, and attachment content — designed for AI agents doing test failure analysis.

License: MIT Node.js: 22+

Related MCP server: mcp-playwright-test

What it is

Playwright Report MCP gives an AI agent structured, token-efficient access to Playwright test outcomes. It runs your test suite, reads the JSON reporter output, and surfaces exactly what the agent needs: which tests failed, what the errors were, and the content of relevant attachments.

What it is NOT

There are many Playwright MCP servers that control a browser — they navigate pages, click elements, fill forms, and take screenshots. Playwright Report MCP is not one of those.

	Browser automation MCPs	Playwright Report MCP
Examples	`microsoft/playwright-mcp`, `executeautomation/mcp-playwright`	this project
Purpose	Let an AI agent drive a browser	Let an AI agent read test results
Runs tests	No	Yes
Returns pass/fail	No	Yes
Surfaces error messages	No	Yes
Reads attachment content	No	Yes

Why

The problem with existing approaches

Default reporters (list / dot) — Playwright's default reporters print human-readable output to stdout. Compact, but lossy: no attachment paths, no retry breakdown, no structured data.

HTML reporter (report.html) — A self-contained SPA bundle (typically 2–50 MB). Not machine-readable as text and exceeds any LLM context window.

Reading results.json directly — Works, but a full JSON report for even a small test suite is 10,000–20,000 tokens. For a failing test, most of that is passing test metadata you don't need.

What Playwright Report MCP does instead

Filters results.json to only failed tests
Returns structured, typed JSON the agent can act on immediately
Exposes individual attachments by name so the agent fetches only what it needs
Works on results produced by anyone — CI pipeline, a human, or the agent itself

Token cost comparison (one failed test in a 20-test suite)

Approximate input token counts based on Claude tokenization (~3–4 characters per token for mixed JSON/text content).

What you need	Without MCP — approach	Tokens (no MCP)	With MCP — tool calls	Tokens (MCP)	Savings
Error message only — live run	`npx playwright test`, read stdout (`list`/`dot`)	~500–1,200	`run_tests` + `get_failed_tests`	~300–500	~2×
Error message only — existing results	Read full `results.json`	~12,500–23,000	`get_failed_tests`	~300–500	~25–45×
+ page state at failure	+ read `error-context` file	~15,000–26,000	+ `get_test_attachment('error-context')`	~2,800–3,500	~4–7×
+ custom text attachments¹	+ read attachment files	~16,200–28,500	+ `get_test_attachment` ×2	~3,300–5,500	~4–5×
+ full page HTML snapshot²	+ read snapshot file	~41,000–103,000	+ `get_test_attachment`	~33,300–85,500	~1.2×

¹ Custom text attachments — e.g. AI diagnosis (~500–2,000 tokens) and console logs (~200–500 tokens) added via testInfo.attach() in your own fixtures.
² Full page HTML snapshot — a custom fixture that attaches the full rendered page HTML on failure. Large pages alone can reach 30,000–80,000 tokens and dominate cost regardless of whether MCP is used.

Key observations:

For a live run, stdout (list/dot) is compact but gives the agent no path to attachment content — dead end for deeper analysis
Reading results.json directly costs ~12,500–23,000 tokens even when only one test failed — most of it is passing test metadata the agent doesn't need
The biggest MCP gains are in the middle rows: getting error messages + page state from existing results at ~4–45× lower token cost
Full page HTML snapshot dominates cost either way; skipping it in favour of error-context is the single largest optimisation available

CI failure analysis

The primary use case: your CI pipeline runs the tests, the agent picks up the results after the fact and diagnoses failures. get_failed_tests reads results.json regardless of who triggered the run. No re-run needed.

Quick start

1. Install via npx (recommended)

No clone or build step needed — npx downloads and runs the server automatically:

{
  "mcpServers": {
    "playwright-report-mcp": {
      "command": "npx",
      "args": ["-y", "playwright-report-mcp"],
      "type": "stdio"
    }
  }
}

Or build from source:

git clone https://github.com/hubertgajewski/playwright-report-mcp.git
cd playwright-report-mcp
npm install && npm run build

2. Add the JSON reporter to your Playwright project

// playwright.config.ts
reporter: [
  ['json', { outputFile: 'test-results/results.json' }],
  ['html'], // keep any existing reporters
],

3. Register in .mcp.json

{
  "mcpServers": {
    "playwright-report-mcp": {
      "command": "npx",
      "args": ["-y", "playwright-report-mcp"],
      "type": "stdio"
    }
  }
}

4. Ask your AI agent

Run the Playwright tests and tell me what failed.

Compatibility

Tested with Claude Code (CLI). Should work with any MCP-compatible client that supports stdio transport, including Claude Desktop, Cursor, Cline, Windsurf, and Continue.dev — but these have not been verified.

The stdio server supports both MCP protocol eras from one entrypoint:

Modern: protocol revision 2026-07-28, selected by clients using version negotiation (for example, versionNegotiation: { mode: "auto" }).
Legacy: supported 2025-era revisions, selected by clients that use the traditional initialize handshake. This remains the default behavior in the MCP client SDK.

The opening exchange pins one era for the connection lifetime. A client that pins an unsupported revision receives an explicit negotiation error; the server does not silently switch it to another era.

Tools

The project-scoped tools accept an optional workingDirectory parameter — see Multi-worktree support. get_run_status can use either a runId from run_tests with wait: false, or a workingDirectory lookup for the latest tracked run.

`run_tests`

Runs the Playwright test suite and returns structured pass/fail results.

Input	Type	Description
`workingDirectory`	string (optional)	Playwright project directory. Absolute or relative to the MCP server launch directory. Defaults to `"."`. Must be under `PW_ALLOWED_DIRS` — see Multi-worktree support.
`spec`	string (optional)	Spec file path relative to the project directory, e.g. `tests/login.spec.ts`. Must stay within the project directory.
`browser`	enum (optional)	`Chromium`, `Firefox`, `Webkit`, `Mobile Chrome`, `Mobile Safari`
`tag`	string (optional)	Tag filter, e.g. `@smoke`
`timeout`	integer (optional)	Timeout in milliseconds for the whole test run. Defaults to `300000` (5 min). Use a larger value for long suites or a smaller one to fail fast. When the run is killed by this timeout, the tool returns an explicit error rather than a generic non-zero exit.
`wait`	boolean (optional)	Wait for completion before returning. Defaults to `true`. Set to `false` to start a background run and poll it with `get_run_status`.
`updateSnapshots`	enum (optional)	Update snapshot baselines. One of `all`, `changed`, `missing`, `none`. Playwright's default is `missing`; `changed` updates differing + missing. Omit to leave existing baselines alone.
`headed`	boolean (optional)	Run with a visible browser window. Omitting or setting `false` leaves `playwright.config.ts` intact — Playwright has no `--no-headed` flag, so `false` does not force headless when the config sets headed.
`workers`	integer (optional)	Number of parallel workers. Positive integer only; the `"50%"` string form is not yet supported.
`retries`	integer (optional)	Maximum retry count for flaky tests. `0` explicitly disables retries; omit to use the project's config.
`maxFailures`	integer (optional)	Stop the run after this many failures. Positive integer.
`trace`	enum (optional)	Force Playwright tracing mode, overriding `playwright.config.ts`. One of `on`, `off`, `on-first-retry`, `on-all-retries`, `retain-on-failure`, `retain-on-first-failure`, `retain-on-failure-and-retries`.

Returns: exit code, run stats, and a summary of all tests with status, duration, and error per project.

When wait is false, returns immediately with runId, process metadata, compact numeric progress, and current results.json status. Poll get_run_status with that runId until state is completed, failed, or timedOut. The server parses Playwright progress markers such as [528/662] from stdout and discards raw stdout/stderr text so repeated polling stays token-efficient. The server allows one active tracked run per working directory, caps active tracked runs globally, and keeps a bounded history of recent terminal runs, so very old runId values can expire.

`get_run_status`

Returns the current status for a non-blocking run started by run_tests with wait: false.

Input	Type	Description
`runId`	string (optional)	Run identifier returned by `run_tests wait=false`. When present, this selects a specific tracked run.
`workingDirectory`	string (optional)	When `runId` is omitted, returns the latest tracked run for that directory, or `idle` if no match. When supplied with `runId`, it must match that run's directory.

If both fields are omitted, workingDirectory defaults to ".". If no run is tracked for the resolved directory, the tool returns state: "idle" plus results.json metadata and last parsed stats when readable. It does not process-scan for external npx playwright test commands that were not started through this MCP server.

Returns: run state, tracking flag, pid, timestamps, elapsed duration, timeout, command metadata, progress: { current, total }, exit code, signal, spawn/timeout error when present, results.json path/existence/mtime/size/freshness, and parsed report stats when the report was updated after the run started. When progress has not appeared yet, current and total are null; when a terminal run has readable final stats, progress is set to the derived completed total.

`get_failed_tests`

Returns failed tests from the last run with error messages and attachment paths. Does not re-run tests — reads the existing results.json.

Input	Type	Description
`workingDirectory`	string (optional)	See Multi-worktree support. Defaults to `"."`.

Returns: failed test count, titles, file paths, per-project status, error messages, and attachment paths.

`get_test_attachment`

Reads the content of a named text attachment for a specific test from the last run.

Input	Type	Description
`workingDirectory`	string (optional)	See Multi-worktree support. Defaults to `"."`.
`testTitle`	string	Exact test title as shown in the report
`attachmentName`	string	Attachment name, e.g. `error-context`, `ai-diagnosis`, `page-html`

Returns: the attachment content as text. Binary attachments and files over 1 MB are rejected with an error. Attachment paths recorded in results.json that escape workingDirectory (via .. or absolute paths pointing elsewhere) are refused.

`list_tests`

Lists all tests with their spec file and tags without running them.

Input	Type	Description
`workingDirectory`	string (optional)	See Multi-worktree support. Defaults to `"."`.
`tag`	string (optional)	Filter by tag, e.g. `@smoke`

Attachments

Playwright attaches files to failed tests automatically. get_test_attachment can read any text attachment by name.

Attachment name	Source	Present in every project
`error-context`	Playwright built-in — YAML accessibility tree snapshot at the point of failure	Yes
`screenshot`	Playwright built-in — PNG screenshot (binary, not readable)	Yes
`video`	Playwright built-in — WebM video (binary, not readable)	Yes
Custom attachments	Added via `testInfo.attach()` in your fixtures	Depends on project

The error-context attachment is the most useful for projects without custom fixtures — it gives a semantic, structured view of the page at the moment of failure with no setup required.

Installation

Via npx (recommended) — use the npx config shown in Quick start. No local installation needed.

From source:

git clone https://github.com/hubertgajewski/playwright-report-mcp.git
cd playwright-report-mcp
npm install
npm run build

Configuration

Add to your .mcp.json at the root of your project:

{
  "mcpServers": {
    "playwright-report-mcp": {
      "command": "npx",
      "args": ["-y", "playwright-report-mcp"],
      "type": "stdio"
    }
  }
}

Environment variables

Variable	Default	Description
`PW_ALLOWED_DIRS`	`"."` (authorizes only the launch dir)	`path.delimiter`-separated list of directories the `workingDirectory` parameter may point at. Entries may be absolute or relative (resolved once against launch cwd at startup).
`PW_RESULTS_FILE`	`<workingDirectory>/test-results/results.json`	Absolute path to the JSON reporter output file. If set, overrides the per-call default for every call.

Set PW_RESULTS_FILE if your playwright.config.ts writes the report to a non-default location. Leave it unset in multi-worktree setups so each workingDirectory gets its own test-results/results.json.

Multi-worktree support

run_tests, list_tests, get_failed_tests, and get_test_attachment all accept an optional workingDirectory parameter — absolute, or relative to the MCP server's launch directory. get_run_status also accepts workingDirectory when runId is omitted; when runId is supplied, any supplied workingDirectory must resolve to that run's recorded directory. This lets a single long-lived MCP session drive tests across multiple git worktrees without restarting.

Because a Playwright config is a Node module that executes on playwright test startup, the server guards the parameter with an allowlist. Callers that point workingDirectory at a directory outside PW_ALLOWED_DIRS get a structured error and no child process is spawned.

Default (no worktrees). Leave PW_ALLOWED_DIRS unset. The allowlist becomes "." — only the launch directory — and the default workingDirectory (also ".") resolves to the launch directory. Zero configuration.

Sibling worktrees. Set PW_ALLOWED_DIRS=".." in your .mcp.json to authorize every sibling of the launch directory. Relative entries resolve against the launch cwd at startup, so the same .mcp.json works for every contributor without baking in absolute paths:

{
  "mcpServers": {
    "playwright-report-mcp": {
      "command": "npx",
      "args": ["-y", "playwright-report-mcp"],
      "env": { "PW_ALLOWED_DIRS": ".." },
      "type": "stdio"
    }
  }
}

Then point calls at any sibling worktree:

{
  "name": "run_tests",
  "arguments": { "workingDirectory": "../my-app-feat-auth" },
}

Multiple projects. Either launch the MCP client from each project and use the default allowlist, or set PW_ALLOWED_DIRS to the shared parent and pass workingDirectory per call. The allowlist check runs at a path-segment boundary, so an entry authorizing /src/my-app will not authorize /src/my-app-evil.

Breaking change (2.x → next): the PW_DIR env var has been removed. Either launch the MCP client from inside the Playwright project directory (zero-config, default workingDirectory: "." works), or pass workingDirectory per call and set PW_ALLOWED_DIRS accordingly.

Requirements

Node.js 22+
@playwright/test 1.40 or later
JSON reporter configured in your Playwright project

Playwright's default reporters (list locally, dot on CI) write to stdout only — they produce no file that can be read after the run. Add the JSON reporter alongside whatever reporters you already use:

// playwright.config.ts
reporter: [
  ['json', { outputFile: 'test-results/results.json' }],
  ['html'],  // keep any existing reporters
  ['list'],
],

Troubleshooting

No results.json found — run tests first

The JSON reporter is not configured or is writing to a different path. Verify your playwright.config.ts has ['json', { outputFile: 'test-results/results.json' }].

list_tests parsed 0 tests from non-empty output

The --list output format may have changed in your version of Playwright. Open an issue with your Playwright version and the raw stdout output.

Attachment "..." is binary and cannot be returned as text

screenshot and video attachments are binary files. Use get_failed_tests to get attachment paths and open them directly if needed.

Attachment "..." is too large to return inline

The attachment exceeds 1 MB. Read the file directly from the path returned by get_failed_tests.

Development

npm test          # run tests once
npm run test:watch  # watch mode

Runtime code lives under src/ and compiles to dist/. Tests use Vitest with focused unit coverage for helpers plus MCP tool integration coverage via InMemoryTransport. No build step or Playwright installation required to run the regular test suite.

Cutting a release

Releases are produced by pushing a v* tag. .github/workflows/release.yml picks up the tag, verifies the tag matches all three version fields, runs npm ci + npm run build + npm test, creates a GitHub Release with auto-generated notes categorized per .github/release.yml (Features / Bug fixes / Documentation / Dependencies / Other changes), and publishes to npm. .github/workflows/publish-mcp.yml then chains off Release via workflow_run and publishes server.json to the MCP registry. Merging to main does not trigger a publish.

Version lives in three places and all three must match the tag before pushing it:

package.json → version
server.json → top-level version
server.json → packages[0].version

Bump all three in one PR and merge to main before cutting the release. release.yml fails the run if the tag disagrees with any of these values.

Ritual:

# After the version-bump PR has merged to main:
git checkout main && git pull
git tag v1.0.5
git push origin v1.0.5
# → release.yml fires: verifies tag, builds, tests, creates GitHub Release, publishes to npm
# → publish-mcp.yml chains off Release and publishes server.json to the MCP registry

Flow:

Open a bump PR that updates all three version fields. Merge it to main.
Tag the bump commit v<version> and push the tag.
release.yml verifies tag/version alignment, runs npm ci, confirms the version is not already published on npm, runs npm run build + npm test, creates the GitHub Release, then publishes to npm with npm publish --access public --provenance.
publish-mcp.yml (triggered by workflow_run on Release) re-verifies the version fields, confirms the version is not already on the MCP registry, and publishes server.json to registry.modelcontextprotocol.io.

No repository secrets required. Both npm and the MCP registry authenticate via GitHub OIDC (npm trusted publishers). The trusted publisher for npm is configured on npmjs.com under the package's Settings → Publishing access → Trusted Publisher section — no NPM_TOKEN secret exists or is needed.

Recovery from a failed publish: npm refuses to republish an existing version and restricts unpublishing after 72 hours. If a publish fails for any reason, bump to the next patch version in a new PR and cut a new release — do not try to re-run the failed release.

Contributing

See CONTRIBUTING.md for bug reports, pull requests, development setup, and commit conventions.

License

MIT — Copyright (c) Hubert Gajewski

Available Tools

5 tools

get_failed_testsA

Return failed tests from the last run with error messages and attachment paths.

ParametersJSON Schema

Name	Required	Description	Default
`workingDirectory`	No	Playwright project directory. Absolute or relative to the MCP server launch directory. Defaults to ".". Must be under PW_ALLOWED_DIRS.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It conveys that this is a read operation returning error messages and attachment paths, but it does not disclose behavior when no previous run exists, whether results are ordered/filtered, or any side effects. It adds some value but remains minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that states the action, the target, and the key output fields. Every word contributes value, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter getter with no output schema, the description provides enough information to select and invoke the tool, including what the result contains. It only lacks explicit edge-case behavior such as the absence of a prior run, but this does not make the tool unusable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter workingDirectory has 100% schema description coverage, so the baseline applies. The tool description does not add any parameter-specific meaning, but the schema already documents the parameter thoroughly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and a clear resource ('failed tests from the last run'), and it names the included contents ('error messages and attachment paths'). This distinguishes it from sibling tools like get_run_status and get_test_attachment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'From the last run' implies usage after test execution, giving some context, but the description does not explicitly state when to use this tool over siblings such as get_run_status or when not to use it. The guidance is inferred rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_run_statusA

Return status for a tracked Playwright run. Pass runId for a specific background run, or omit it to inspect the latest tracked run for a workingDirectory. If no tracked run exists, returns idle with current results.json metadata; it does not inspect unrelated OS processes.

ParametersJSON Schema

Name	Required	Description	Default
`runId`	No	Run identifier returned by run_tests with wait=false.
`workingDirectory`	No	Playwright project directory. Absolute or relative to the MCP server launch directory. Defaults to ".". Must be under PW_ALLOWED_DIRS. Used to find the latest tracked run when runId is omitted; when supplied with runId, it must resolve to that run working directory.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses a key behavioral limitation ('does not inspect unrelated OS processes') and explains the fallback behavior when no tracked run exists ('returns idle with current results.json metadata'). It doesn't enumerate possible status values or confirm read-only nature, but the negative statement and fallback provide meaningful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, starts with the core purpose, and efficiently conveys the parameter alternatives and edge-case behavior in the second sentence. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status-check tool with no output schema, the description covers the main invocation scenarios, the fallback, and explicitly scopes what it does not do. It could specify possible status values, but the mention of results.json metadata gives enough context for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage with detailed descriptions for both runId and workingDirectory, including their relationship. The description paraphrases the runId/workingDirectory conditional logic but adds no new parameter-level meaning beyond the schema. Therefore, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Return status for a tracked Playwright run.' It uses a specific verb and resource, and distinguishes itself from generic process inspection by noting it only handles tracked runs, not unrelated OS processes. This separates it from siblings like run_tests and get_failed_tests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit conditional guidance: pass runId for a specific background run, or omit it to use workingDirectory for the latest tracked run. It also explains the edge case when no tracked run exists. However, it does not explicitly name alternative sibling tools or say when not to use this tool, so it's clear but not fully comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_test_attachmentA

Read the content of a named attachment for a specific test from the last run.

ParametersJSON Schema

Name	Required	Description
`testTitle`	Yes	Exact test title as shown in the report
`attachmentName`	Yes	Attachment name, e.g. "AI diagnosis", "DOM"
`workingDirectory`	No	Playwright project directory. Absolute or relative to the MCP server launch directory. Defaults to ".". Must be under PW_ALLOWED_DIRS.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It indicates a read-only operation by using 'Read', but does not mention potential errors (e.g., missing test attachment), format of returned content, or any limitations. This is adequate but leaves room for more transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that conveys the essential purpose without redundancy. It is front-loaded with the verb and resource, and every word contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with no output schema and no annotations, the description provides enough to understand the tool's primary function. However, it lacks detail on return format or failure behavior, which could be important for agent usage. Given the low complexity, a 4 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all parameters with descriptions, so baseline 3 applies. The tool description itself adds little beyond the schema, though it reinforces the relationship between testTitle and attachmentName. No additional semantics are provided beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the verb ('Read'), the resource ('content of a named attachment'), and the scope ('for a specific test from the last run'). It distinguishes the tool from siblings like run_tests and list_tests, which focus on execution and listing, not reading attachments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to read an attachment for a specific test from the last run) and provides clear context. It does not explicitly list alternatives or exclusions, but the sibling tools are sufficiently distinct that no confusion arises.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_testsA

List all tests with their spec file and tags without running them.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Filter by tag, e.g. @smoke
`workingDirectory`	No	Playwright project directory. Absolute or relative to the MCP server launch directory. Defaults to ".". Must be under PW_ALLOWED_DIRS.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the transparency burden. It discloses the key behavioral trait of not running tests and mentions the output (spec file, tags). However, it does not elaborate on side effects, scope limits, or return format, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the verb and resource, with zero filler. It efficiently communicates the core purpose and key distinction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with only two optional parameters and no output schema. The description covers the purpose, output content, and the non-execution behavior, which is sufficient for basic use. It could mention the workingDirectory scope more explicitly, but the schema handles that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are well-documented in the schema. The description adds no additional parameter semantics but does mention what output fields are included, which is not directly in the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('list') and resource ('all tests') and clarifies the output ('spec file and tags'). The phrase 'without running them' explicitly differentiates it from the sibling tool 'run_tests'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by stating 'without running them,' which signals this is for inspection only and contrasts with run_tests. It lacks explicit 'use this instead of X' instructions but provides clear context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_testsA

Run Playwright tests and return structured results.

ParametersJSON Schema

Name	Required	Description
`tag`	No	Tag filter, e.g. @smoke or @regression
`spec`	No	Spec file path, e.g. tests/navigation.spec.ts
`wait`	No	Wait for completion before returning. Defaults to true. Set false to start a background run and poll it with get_run_status.
`trace`	No	Force Playwright tracing mode, overriding playwright.config.ts.
`headed`	No	Run with a visible browser window. Omitting or setting false leaves playwright.config.ts intact — Playwright has no --no-headed flag, so false does not force headless when the config sets headed.
`browser`	No
`retries`	No	Maximum retry count for flaky tests; 0 disables retries.
`timeout`	No	Timeout in milliseconds for the whole test run. Defaults to 300000.
`workers`	No	Number of parallel workers (positive integer).
`maxFailures`	No	Stop the run after this many failures.
`updateSnapshots`	No	Update snapshot baselines. Playwright default is "missing"; "changed" updates differing + missing.
`workingDirectory`	No	Playwright project directory. Absolute or relative to the MCP server launch directory. Defaults to ".". Must be under PW_ALLOWED_DIRS.

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. The single sentence only states the action and output, without disclosing side effects, defaults, backgrounding behavior, or permissions. It says results are structured but gives no further behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no unnecessary words, immediately stating the action and output. It is appropriately concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 12 parameters and no output schema, yet the description does not explain return values or the overall workflow (e.g., how background runs interact with get_run_status). It relies heavily on parameter descriptions, leaving the agent to piece together usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 92%, so baseline is 3 even without parameter info in the description. The main description adds no parameter semantics beyond the schema's detailed per-parameter explanations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Run Playwright tests') and clearly states the output ('return structured results'). This distinguishes it from sibling tools like get_run_status or list_tests, which handle monitoring or listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The main description implies the primary use case (running tests). The schema's 'wait' parameter explicitly mentions using get_run_status for background runs, providing an alternative. However, there are no explicit exclusions or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv3.3.0Aug 12, 2026

Changedget_failed_tests1 field changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changedget_run_status1 field changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changedget_test_attachment1 field changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changedlist_tests1 field changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changedrun_tests1 field changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

5 tool updatesv3.2.2Jun 11, 2026
- First observedget_failed_tests
- First observedget_run_status
- First observedget_test_attachment
- First observedlist_tests
- First observedrun_tests

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: running tests, checking status, retrieving failures, reading attachments, and listing tests. There is no ambiguity between them, and descriptions further clarify boundaries.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (run_tests, get_run_status, get_failed_tests, get_test_attachment, list_tests). The naming is uniform and predictable.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose. Each tool fills a necessary role without redundancy or bloat.

Completeness3/5

The core workflow of running tests and retrieving failures is covered, but there is no direct way to retrieve all test results (including passed tests) from a background run. Users must either rely on the synchronous run_tests response or infer pass status by absence from failures, which is a notable gap.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
Zyntra - Temp e-mails MCP A
app.zyntra.mcp
MCP server for e-mail testing: create disposable inboxes, wait for delivery, and extract e-mail content or links - all from your AI agent or test automation workflow. Get a free API key on https://app.zyntra.app/
Developer Tools Email Testing & QA Tools
2
mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2

Related MCP Servers

browser-devtools-mcp
Browser Automation Developer Tools Observability
serkan-ozal
A
license
Not graded
quality
Not graded
maintenance
A Playwright-based MCP server that exposes a live browser as a traceable, inspectable, debuggable and controllable execution environment for AI agents.
Updated 7 months ago (2026-01-27 17:50 UTC)
5,218
57
-
mcp-playwright-test
Testing & QA Tools App Automation Developer Tools
owen-whf
A
license
Not graded
quality
D
maintenance
An MCP server that automates Playwright-based UI and API testing, supporting test case generation from requirements or API specs, and execution with detailed reports.
Updated a year ago (2025-07-10 02:20 UTC)
17
1
MIT
visual-ui-debug-agent-mcp
Browser Automation Testing & QA Tools Developer Tools
samihalawa
A
license
C
quality
A
maintenance
An MCP server that enables AI agents to autonomously test, debug, and analyze web interfaces visually using Playwright, with 30 tools for screenshots, workflows, performance, and visual comparison.
Updated a month ago (2026-08-11 00:44 UTC)
30
40
81
ISC
playwright-mcp
Browser Automation Testing & QA Tools
ademdeniz
F
license
A
quality
B
maintenance
An MCP server that gives Claude direct control of a real browser via Playwright, enabling AI-driven web testing, autonomous test execution, and live failure analysis through natural language.
Updated a month ago (2026-08-06 03:15 UTC)
8
9,320
3
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hubertgajewski/playwright-report-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Playwright Report MCP

Table of contents

What it is

What it is NOT

Why

The problem with existing approaches

What Playwright Report MCP does instead

Token cost comparison (one failed test in a 20-test suite)

CI failure analysis

Quick start

Compatibility

Tools

run_tests

get_run_status

get_failed_tests

get_test_attachment

list_tests

Attachments

Installation

Configuration

Environment variables

Multi-worktree support

Requirements

Troubleshooting

Development

Cutting a release

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`run_tests`

`get_run_status`

`get_failed_tests`

`get_test_attachment`

`list_tests`