playwright-e2e-mcp

Analyze run history

analyze-history

Read-onlyIdempotent

Analyze local Playwright run history to rank flaky tests, group failure patterns, track slow tests and trends, and name the commit where each failure began.

Instructions

Analyze the local run history (.playwright-e2e-mcp/history.jsonl, written by every run and load-report): 'flaky' ranks tests that flip pass/fail and lists broken or regressed ones; 'patterns' groups failures by cause; 'test' shows one test's timeline; 'slow' ranks durations and slowdowns; 'trend' shows stability per day; 'commits' names the commit where each failing or flaky test went bad.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "analyze-history"
  }
}

Input Schema

Name	Required	Description
`test`	No	Filter: substring of file or title
`view`	No	Default 'flaky'; 'slow' ranks durations, 'trend' is per day, 'commits' names the commit each test went bad
`limit`	No
`source`	No	With a shared history server (PW_MCP_HISTORY_URL): 'both' (default) merges this machine's runs with CI runs from it; 'cloud' or 'local' for one side
`lastRuns`	No	Runs to analyze (default 30)
`projectRoot`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.13.0Nov 2, 2026

removedInput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -{}
```

changedInput schema / properties / source / description

Previous value: -"With a Pro key: 'both' (default) merges this machine's runs with CI runs from Pro Cloud; 'cloud' or 'local' for one side"New value: +"With a shared history server (PW_MCP_HISTORY_URL): 'both' (default) merges this machine's runs with CI runs from it; 'cloud' or 'local' for one side"

Changed1 schema field changedv0.7.0Oct 29, 2026

addedInput schema / properties / source

Added value: +{
+  "description": "With a Pro key: 'both' (default) merges this machine's runs with CI runs from Pro Cloud; 'cloud' or 'local' for one side",
+  "enum": [
+    "local",
+    "cloud",
+    "both"
+  ],
+  "type": "string"
+}

Changed3 schema fields changedv0.6.1Oct 27, 2026

addedInput schema / additionalProperties
```
Added value: +{}
```

changedInput schema / properties / view / description

Previous value: -"Default 'flaky'"New value: +"Default 'flaky'; 'slow' ranks durations, 'trend' is per day, 'commits' names the commit each test went bad"

changedInput schema / properties / view / enum

Previous value: -[
-  "flaky",
-  "patterns",
-  "test"
-]New value: +[
+  "flaky",
+  "patterns",
+  "test",
+  "slow",
+  "trend",
+  "commits"
+]

First observedv0.3.2Oct 20, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds real context by naming the on-disk history file and its writers, but says nothing about what happens when the file is absent or empty, how much history must exist before rankings are meaningful, or pagination/truncation behavior.

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

Conciseness4/5

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

One dense sentence that front-loads the purpose and data source before enumerating views, with zero marketing filler. It is long, but nearly every clause carries information an agent needs to choose a view.

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

Completeness3/5

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

With 6 optional parameters, no output schema, and 67% schema coverage, the description covers view semantics but leaves the return shape, empty/short-history behavior, and projectRoot's effect on which history file is read unspecified. Adequate to invoke, but not fully self-sufficient for a tool whose whole value is its output interpretation.

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

Parameters4/5

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

Schema coverage is 67%, and the description fills several gaps: it explains the semantics of 'flaky', 'patterns', and 'test' views that the schema's view description omits, and clarifies that 'test' ties to a single test's timeline. It still doesn't clarify how the 'test' substring filter interacts with the 'test' view, or what projectRoot changes about the history location.

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?

States a specific verb and resource ('analyze the local run history') and pins down the data source file plus who writes it. The six view names are each given a one-clause meaning, so an agent can tell exactly what the tool produces, which differentiates it from point-in-time siblings like diagnose-flaky or bisect-failure.

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 view enumeration functions as usage guidance: 'flaky' for pass/fail flips, 'patterns' for failure grouping, 'test' for a single timeline, 'slow' for durations, 'trend' for per-day stability, 'commits' for culprit commits. It is clear what each mode is for, but there is no explicit routing advice versus siblings such as diagnose-flaky and no stated preconditions.

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