Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LOG_LEVELNodebug | info | warn | error | silent; LOG_LEVEL wins when both LOG_LEVEL and MCP_LOG_LEVEL are set.info
LOG_FORMATNotext, or json (also ndjson) for one structured JSON object per line.text
PW_MCP_TOOLSNoWhich tools to expose, as tool names and/or profiles, comma separated (same as the --tools= flag). Profiles: core, triage, inspect, author.all
MCP_LOG_LEVELNoAlias of LOG_LEVEL; used when LOG_LEVEL is not set. Default info.
MCP_LOG_FORMATNoAlias of LOG_FORMAT; used when LOG_FORMAT is not set. Default text.
PW_MCP_HISTORYNoSet to 0 to stop recording runs to .playwright-e2e-mcp/history.jsonl.
PW_MCP_HTTP_TOKENNoHTTP bridge only: bearer token (16+ characters) that unlocks all tools.
PW_MCP_MAX_CHILDRENNoHTTP bridge only: how many test runs and browser probes may run at once.4
PW_MCP_PROJECT_ROOTNoDefault project root for every tool. Defaults to the server's working directory.
PW_MCP_ALLOWED_HOSTSNoHTTP bridge only: comma-separated Host allowlist; `*` accepts any.
PW_MCP_ALLOWED_ROOTSNoExtra directories a caller may pass as projectRoot (`:`-separated, `;` on Windows).
PW_MCP_STORAGE_STATENoDefault storageState file (inside the project) for the page tools.
PW_MCP_PASSTHROUGH_ENVNoHTTP bridge only: comma-separated extra variables passed to test runs (e.g. BASE_URL).
PW_MCP_BLOCK_PRIVATE_URLSNoSet to 1 to make the URL tools refuse loopback, private-network and cloud-metadata addresses. Default off (on for the HTTP bridge).

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
run-testA

Run the project's Playwright tests: stats plus each failure's file:line, kind and message. Diagnoses missing installs, dead dev servers, syntax errors, crashes and timeouts (kills the tree, keeps partial results). Reports progress; background: true returns a run id for long suites. Runs are recorded for analyze-history.

get-run-statusA

Progress (tests done/total, failures so far) or the final result of a run-test background run; the result becomes the last run for get-failure. waitSeconds waits; cancel stops it. Default: the latest run.

get-failureA

Analyze one failure from the most recent run-test execution: full message and code frame, expected vs actual, stack trace, failed network requests (4xx/5xx and dead endpoints), console errors, failure kind (assertion/timeout/browser-crash/syntax/config/server-unreachable) and concrete next steps. Use run-test first.

suggest-fixA

Patch a failure from the last run: a drifted locator is matched against the DOM at failure (trace, or live url) and replaced with one proven unique; changed copy gets the new expected text. Returns a diff and confidence; apply: true writes it, re-runs the test and reverts if still red. Refuses when the element is truly missing (app bug).

inspect-pageA

Open a URL headlessly and return its elements with Playwright locators proven unique on the page (role + name first), CSS selectors, visibility, text and console messages. storageState/headers open it signed in; actions click/fill first to reach a state. view 'locators' is the compact map.

list-testsA

List the Playwright tests available in the project (file, line, full title, projects), with optional filtering. Uses playwright test --list when Playwright works and falls back to a source scan when the install or config is broken, reporting why.

validate-selectorA

Check a CSS selector, Playwright selector or locator (getByRole/getByTestId…, .first(), .filter()) on a live page: validity, match count (actions need exactly 1), sample matches and a sturdier verified locator for each. Accepts storageState/headers/actions.

generate-e2e-testA

Scaffold a Playwright test from a description using the project's REAL selectors. Scans the agent's recent file changes (git working tree / last commit, mtime fallback), extracts data-testid / role / label / placeholder / id locators with their source locations, optionally cross-checks them against the live page, writes a ready-to-run spec, and returns next steps.

compare-visual-stateA

Visual regression check: screenshot a live page (or element), compare it to a stored baseline, and report how many pixels changed, WHERE they changed (bounding regions), and the average color shift ("blue → red"). First call saves the baseline; later calls compare. Writes a red-highlighted diff image for review.

diagnose-flakyA

Repeat failing tests with retries disabled and return a per-test, evidence-based verdict: CONSISTENTLY FAILING (real bug), FLAKY (pass/fail counts, error-signature variance, duration spread) or NOT REPRODUCING. Runs all repetitions in one process by default. isolate: true also re-runs the failures with one worker to tell parallelism bugs (shared state) from flakiness inside the test. Defaults to the tests that failed in the most recent run.

analyze-historyA

Analyze the local run history (.playwright-e2e-mcp/history.jsonl, written by every run): 'flaky' ranks tests that flip pass/fail and lists broken or regressed ones; 'patterns' groups failures by cause; 'test' shows one test's timeline.

Prompts

Interactive templates invoked by user choice

NameDescription
fix-failing-testRun the tests, diagnose the first failure, apply a verified fix or explain the real bug.
triage-flaky-testsRank unstable tests from the local run history and diagnose the worst one.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 11 tools

Disambiguation4/5

The tools form a clear pipeline (run-test → get-failure → suggest-fix) with distinct analysis tools (analyze-history for history, diagnose-flaky for re-running), so most purposes are separable. However, inspect-page vs validate-selector overlap (both surface live-page locators), and analyze-history's 'flaky' view vs diagnose-flaky could be confused by an agent unsure which layer to use.

Naming Consistency5/5

Every name follows a verb_noun kebab-case pattern (run-test, get-failure, suggest-fix, list-tests, validate-selector, generate-e2e-test, compare-visual-state, diagnose-flaky, analyze-history, inspect-page, get-run-status). The only minor deviation is the compound verb in get-run-status, which is still readable and consistent.

Tool Count5/5

11 tools is well within the sweet spot and each maps to a real step in the e2e workflow (run, inspect, diagnose, fix, scaffold, visual-check). Nothing feels padded or redundant at the count level.

Completeness4/5

The surface covers the full diagnose-and-fix lifecycle plus test generation, listing, selector validation and visual regression. Minor gaps exist: no explicit tool to manage/reset visual baselines or clean run artifacts, though agents can work around these.

Maintenance

ActivityMaintained
ResponsivenessNo issues