Applitools

Setup step: add eyes.check() visual checkpoints to an existing Playwright test file. Edits source, not results.

Coarse diff regions for a step, clustered from raw pixel-level differences. Each region includes a diffCount. Already reflects any match regions added during resolution — a masked area no longer shows up here. Run this before fetching any images or DOM data for a step. Resolution can happen between calls, so never reuse an earlier result in this conversation — call it again. A low-level primitive: for a driven step-level review, call eyes_review_progress with scope: "step" instead — it calls this internally for every changed area.

Export a DOM capture as JSON, saved to a file. `domId` comes from eyes_inspect_steps (baseline.domId or checkpoint.domId per step). Use to inspect exact computed styles/structure, or to locate an element's rect/id for use elsewhere (e.g. as an eyes_inspect_history nodeId). Returns a file path — pass it directly to the Read tool, or search it with eyes_inspect_dom_search rather than writing an ad-hoc script.

Structural DOM diff between a step's baseline and checkpoint. `rect`, if given, only filters the output, not the comparison itself. Entries are tagged `changed`/`new`/`missing`/`displaced`. Already omits any structural difference that doesn't correspond to an actual visual diff under the step's current match settings/regions — masking a change elsewhere no longer produces DOM-diff noise. Always run this for a step before concluding a visual diff is rendering noise, and before summarizing large diffs (which are often caused by displacement — this reveals the root cause directly). The diff is computed server-side and this call may take up to ~20 seconds before responding — that is normal, do not abort early; if the call is interrupted anyway, the computation continues server-side — call this tool again with the same arguments and it resumes, usually instantly. A large diff can outlive the wait budget, in which case the result is `{"status":"computing","taskId",...}` instead of the diff — always follow its `next` field exactly (re-call this tool with the same arguments plus that taskId); the diff is ONLY available through that follow-up call, never by inferring it from images or prior context. If a diff here is the exact same underlying change you've already recorded elsewhere in this scenario, eyes_review_diff_report's `sameAs` argument lets you skip straight to reviewing just the checkpoint image for it. Resolution can happen between calls, so never reuse an earlier result in this conversation — call it again.

Search a DOM capture file (written by eyes_inspect_dom) for elements matching a boolean predicate — always use this instead of writing an ad-hoc script (Python/Node/jq/grep/manual JSON.parse) to search a capture. Full predicate grammar and examples: read the "eyes-inspect://dom-search-grammar" resource. Condensed cheat-sheet below for clients that don't fetch resources. Searches a DOM capture file (written by eyes_inspect_dom) for elements matching a boolean predicate, printing one compact line per match, indented by tree depth. Predicate kinds (combine with 'and'/'or'/'not' and parentheses): - Property comparison: tagName = 'DIV', attributes.class contains 'btn', rect.width > 200, style.display != 'none', attributes.href starts-with 'https://', tagName =~ /^H[1-6]$/, attributes.type in ('button','submit') - Geometry: bounds contains 400,300 | bounds contains 0,0,500,200 | bounds intersects node 12 | bounds contained-by node 12 - Relationship: child-of (tagName = 'UL'), descendant-of node 5, sibling-of node 7 - Shortcut keywords: image, gif, logo, button, hidden (and others) - Reference another element by its 'id' field with 'node <id>' Values with spaces must be single-quoted; string comparisons are case-insensitive. Every matched element also exposes a virtual 'text' property (its own concatenated text content).

Everything needed to review a step's changed areas, in one call: for each area, the image diff (checkpoint with differences highlighted in pink) plus the baseline and checkpoint screenshots, fetched together. Pass EVERY area you still have to review in a single call's `areaRects` — one call per area is exactly what this tool exists to avoid. Pass each rect exactly as eyes_review_progress gave it to you — do NOT pad it, the server pads it and clamps it to each image. Prefer this over calling eyes_inspect_image_diff and eyes_inspect_image separately; it is what eyes_review_diff_report's gate checks for. It also returns the whole step's structural DOM diff under `domDiff` and the match regions currently in effect under `regions`, so do not call eyes_inspect_dom_diff or eyes_inspect_regions separately for this step — the one exception is a `domDiff` or `regions` reporting `status: "computing"` or `status: "error"` (with the failure's own message under `error`), whose own `next` says where to pick it up. The composed `domDiff` waits only briefly, so `status: "computing"` is common and expected here — the images ship without waiting for it; follow its `next` to eyes_inspect_dom_diff, which is where the diff is waited out. Returns `evidence`, one entry per area in the order asked for, each with a labelled file path per image, plus the images themselves for clients that render them — read each `path` only for an image whose `inline` is false, and `notInlined` says why it was not. Inlined images arrive as image blocks in the same order as the `inline: true` entries, reading `evidence` top to bottom; `inlining` reports how much of the budget the response spent. Each image carries the `rect` it was actually cropped at: the two sides of a step can differ in size, so the crops are near-identical but NOT guaranteed equal — compare by content, and check the rects before reading anything into a difference in position or extent. Any image this step cannot produce for an area is lis…

For each given node id, a changelog of non-empty diffs against prior runs of the same test scenario and environment, keyed by node id. Use before concluding whether a changed or drifted element is dynamic (recurring changes) versus a one-time real change — never guess this from a single run alone. An empty array for a node means no change was found across however much history was searched; that alone is not proof of anything either way. Each historic comparison is computed server-side, so this call can take up to ~20 seconds per comparison — do not abort early; if the call is interrupted or reports a still-computing comparison, call it again with the same arguments and the walk resumes from cache.

Export a baseline or checkpoint screenshot as a PNG, cropped to `rect` if provided. `imageId` comes from eyes_inspect_steps (baseline.id or checkpoint.id per step). Returns a file path, self-identifying by imageId and crop rect — pass it directly to the Read tool.

Export the checkpoint screenshot with visual differences highlighted in pink, cropped to `rect` if provided. Returns a file path — pass it directly to the Read tool to view the image. Pad a changed-area rect by 10px on every side before requesting it here; the region may exceed the image bounds, which is fine. Already reflects any match regions added during resolution — a masked area is no longer highlighted. Resolution can happen between calls, so never reuse an earlier result in this conversation — call it again.

The match regions currently in effect for a step (ignore/strict/layout/dynamic/etc.), optionally filtered to those intersecting `rect` on either side. Returns `{ regions, codedRegions }`: `regions` are the regions defined on the step's baseline, or changed by a reviewer through resolution (a domSelector present on one side but empty on the other means that side's anchor is stale, or its target genuinely doesn't exist there); `codedRegions` are regions provided by the test code itself, keyed by regionId instead.

List sessions in an Applitools Eyes batch plus batch-wide stats. `filter` narrows to unresolved/unsaved/mismatching sessions; `format` shapes the output (`full` default: stats+session list; `stats`: stats only; `scenarios`: deduplicated, sorted session names only). A low-level primitive: for reviewing or resolving a batch's results, call eyes_review_progress with scope: "batch" instead — it drives the full investigation and calls this internally.

Session summary (sessionId, sessionName, appName, status, isUnsaved, isAborted, environment, startedAt) plus every test step with baseline/checkpoint image IDs, domIds, sizes, match status (isMatching), resolution, and per-step isUnsaved. A low-level primitive: for reviewing or resolving a session's results, call eyes_review_progress with scope: "session" instead — it drives the full investigation and calls this internally. Call this directly only when you need raw step data outside a driven review, e.g. an image id for eyes_inspect_image.

Marks a step's checkpoint image as accepted or rejected, per `action` — see its own description for what each one does to the baseline. Only call this once the step's differences have actually been investigated and judged (see the eyes_inspect_* tools). By default also accepts (or rejects) every other still-unresolved step that genuinely shares this step's diff, across this session and same-scenario siblings — see propagate; a candidate that already has its own accept/reject decision is left alone. A low-level primitive: for a driven review that also resolves what it finds, use eyes_review_progress with mode: "resolve" instead — it calls this deterministically from its own findings. Call this directly only for a one-off manual decision outside that review.

Adds/removes/updates a step's ignore or match regions, with every regionOp's ids/rects read against the BASELINE or CHECKPOINT image/DOM per `target` (mapped onto whichever side the step's current resolution actually needs). Does not itself change accept/reject. Propagates by default (see propagate) since masking confirmed-dynamic content applies regardless of a sibling's own accept/reject verdict. Returns one entry per touched step, each listing the regions actually changed by each input regionOp (a clear op is reported as the concrete regions it removed). A low-level primitive: for a driven review that also resolves what it finds, use eyes_review_progress with mode: "resolve" instead — it calls this deterministically from its own findings. Call this directly only for a one-off manual fix outside that review.

Restores every in-scope session's baseline to the revision the test originally ran against, and clears any pending (unsaved) accept/reject/region resolution back to unresolved. Unlike every other eyes_resolve_*/eyes_inspect_* tool, the URL's shape is not just a locator — it IS the scope: a session URL (even with a /steps/N suffix) resets only that one session, while a bare batch URL resets every session in the batch. If the user asks to reset "the batch"/"everything"/"all sessions" but only a session or step URL is on hand (e.g. reused from an earlier call in this conversation), strip it down to the bare batch form first — passing the session URL as-is will silently under-scope the reset. Destructive and not undoable — only call it with explicit user approval of that exact scope.

Saves every accepted/rejected step and region change in the WHOLE BATCH to the baseline — all of its tests, not just the session in the URL (the server save is batch-scoped; the session part only identifies the batch). A potentially destructive, hard-to-reverse operation. Only call it once the user has explicitly approved committing the changes just made.

Records the rich per-diff evidence for the changed areas of one step — one `reports` entry per area, every unreviewed area of the step in a single call, and every finding fully specified for its claimed category. Each entry is verified on its own, against its own areaRect: it hard-throws if eyes_inspect_evidence wasn't actually fetched for that areaRect, a finding claims dynamic.justification:"History" with no matching eyes_inspect_history call, a finding proposes a dynamic.mask fix with no eyes_inspect_regions call for this step, its mask's `before` doesn't match a region actually in effect right now, or its mask's `after` doesn't cover the finding's own area. Entries are processed in order and stop at the first rejection — the ones before it stay recorded, and the error names exactly which areas to send back. If an area is the exact same underlying change as an area already recorded in the same scenario, set its entry's `sameAs` instead of redoing the full trio — see its own description. In mode "resolve" each finding's `dynamic.mask` is turned into an actual checkpoint match-region change right here — `mask.after.area`, if left null/omitted, defaults to the finding's own `area` — and the response reports per finding what was added/adjusted (or why it could not be), on `regions` and appended to `description`. Always follow the returned `next` field — it tells you exactly what to do next, whether that's reporting more changed areas or moving up to the step level.

Records the deduplicated findings summary for whatever `scope` names, once eyes_review_progress for that same scope reports every one of its children reviewed — see `scope`'s own description for what each one records, and `findings` for the shape each one takes. Discarded (not an error) if called too early. Always follow the returned `next` field — it tells you exactly what to do, whether that means retrying via eyes_review_progress, reviewing another entity at this same level, moving up to the level above, or the investigation is now fully reviewed.

Tracks progress investigating whatever `scope` names — see its own description for what each one investigates and which arguments it takes. ALWAYS call this to initiate test results inspection at that level, and ALWAYS follow its `next` field for what to call next. Do not report findings or conclusions to the user before this review's own eyes_review_end call reports completion. In mode "resolve" this additionally acts on what it finds: dynamic content is masked with a match region as each diff is reported, and each step is accepted/rejected/left-unresolved deterministically from its own findings — the response's top-level `resolution` and `regions` tallies, plus each finding's own `regions` detail, report exactly what happened.

Get step-by-step instructions to set up a Playwright JS project with Applitools Eyes (Fixtures variant) [CORE REQUIREMENT: URL INTEGRITY] Playwright visual results return URLs ending in ~~. These are not typos. You are strictly forbidden from stripping trailing tildes from these links. Use markdown [Visual Test results](URL with tildes) for links. Output the raw, verbatim URL string exactly as captured from the test output.

Configure Ultrafast Grid (UFG) for cross-browser and cross-device testing [CORE REQUIREMENT: URL INTEGRITY] Playwright visual results return URLs ending in ~~. These are not typos. You are strictly forbidden from stripping trailing tildes from these links. Use markdown [Visual Test results](URL with tildes) for links. Output the raw, verbatim URL string exactly as captured from the test output.

Validate your Applitools API key and optional server URL. Searches for API key in .env, applitools.config.js/ts/cjs/mjs, and playwright.config.js/ts/cjs/mjs files.