Skip to main content
Glama

Audit tests for flake risks

audit-tests
Destructive

Audit Playwright test code for flake risks like hard waits, missing awaits and .only, rank files by past flakiness, and optionally rewrite mechanical findings then re-run and restore files if the run fails.

Instructions

Audit the Playwright test code for flake risks (hard waits, one-shot assertions instead of web-first ones, missing awaits, .only, force clicks, networkidle, element handles, layout selectors) and rank files by how flaky their tests have been in the run history. fix: true rewrites the mechanical ones, re-runs the touched files and restores them if the run fails.

Input Schema

NameRequiredDescriptionDefault
fixNoRewrite the mechanical findings (web-first assertions, missing awaits, .only), re-run the touched files and restore them if the run fails
limitNoMax findings to list (default 50); the summary counts all
configNoplaywright.config path or 1-based index, for the verify run
filterNoCase-insensitive substring filter on the file path
verifyNoWith fix: re-run the touched files (default true)
testDirNoAudit only this directory (inside the project); defaults to the config testDir
timeoutMsNoWall-clock limit for the verify run
historyRunsNoHow many recent runs of the local history to weigh in (default 50)
minSeverityNoReport findings at or above this severity (default low)
projectRootNoProject directory; defaults to the server working directory

Output Schema

NameRequiredDescriptionDefault
okYesfalse when the call failed (see error) or the tests it ran failed
errorNo
totalNo
appliedNo
findingsNo
verifiedNo
truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations flag destructiveHint=true and openWorldHint=true; the description earns credit by explaining exactly what destruction looks like (rewrites mechanical findings, re-runs touched files, restores on failure) — a rollback guarantee the annotations cannot convey. It stops short of noting that without fix:true the call is a non-mutating scan, and says nothing about auth or project prerequisites.

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?

Two sentences, front-loaded with the audit purpose and its risk taxonomy, then the fix behavior. The parenthetical list is long but each item is load-bearing; no filler sentences or restated title.

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?

An output schema exists, so return values need no explanation, and the mutation path is fully described including the restore-on-failure safety net. What's missing is setup context — that a Playwright project/config and local history must exist for the ranking and verify steps to work.

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 100%, so all ten parameters are self-documenting; baseline is 3. The description reinforces fix and hints that history weighting exists, but adds no syntax or interaction detail 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?

States a specific verb+resource (audit Playwright test code for flake risks), enumerates the exact anti-patterns it looks for, and adds a second dimension (ranking files by historical flakiness). This is clearly distinguishable from siblings like diagnose-flaky (single failure) and analyze-history (run data only).

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?

The description explains what fix:true does but never states when to reach for this tool versus diagnose-flaky, analyze-history, or suggest-fix, nor any when-not conditions. Usage is implied (scan-and-optionally-repair) rather than prescribed.

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