
Applitools
Create, update, review, and resolve visual tests with Applitools Eyes across any supported SDK.
Connector by applitools · GitHub account verified by the MCP Registry
Chalk Labs
Need help deploying Applitools?
Chalk Labs sets up agents like this inside real teams: connected to your tools, tested on your data, with a human in the loop where it matters.
Install
Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.
npx agentmarket install connector/applitools-applitools
Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.
Get the weekly diff
The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.
About
Reviews
Write a reviewNo reviews yet. Installed it? Reviews come from verified installers only. How reviews work
Permissions
What this server can do and what it asks for, from its tool list, install config and code. Checked Oct 25, 2026.
- Tools
- 14 read · 5 write · 0 delete · 3 not yet classified
- Secrets
- None asked for
- Install scripts
- None found
- Runs as
- Node.js package
Tools by what they do 22
Read from the source code; the running server may list different tools.
Read 14 · Look things up without changing anything.
eyes_inspect_changed_areaseyes_inspect_domeyes_inspect_dom_diffeyes_inspect_dom_searcheyes_inspect_evidenceeyes_inspect_historyeyes_inspect_imageeyes_inspect_image_diffeyes_inspect_regionseyes_inspect_sessionseyes_inspect_stepseyes_review_progress
Show 2 more tools
eyes_setup_projecteyes_verify_api_key
Write 5 · Create, change, send or run things.
eyes_add_checkpoints_to_testeyes_resolve_checkpointeyes_resolve_regionseyes_resolve_reseteyes_resolve_save
Not yet classified 3 · We could not tell from the name and description.
eyes_review_diff_reporteyes_review_endeyes_setup_ufg
Network hosts it talks to 3
applitools.com· found in codegithub.com· found in coderaw.githubusercontent.com· found in code
Tools (22)
Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].
eyes_add_checkpoints_to_testSetup step: add eyes.check() visual checkpoints to an existing Playwright test file. Edits source, not results.
eyes_inspect_changed_areasread-onlyCoarse 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.
eyes_inspect_domread-onlyExport 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.
eyes_inspect_dom_diffread-onlyDescription is built at runtime.
eyes_inspect_dom_searchread-onlySearch 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…
eyes_inspect_evidenceread-onlyEverything 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 che…
eyes_inspect_historyread-onlyDescription is built at runtime.
eyes_inspect_imageread-onlyExport 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.
eyes_inspect_image_diffread-onlyExport 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.
eyes_inspect_regionsread-onlyThe 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.
eyes_inspect_sessionsread-onlyList 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.
eyes_inspect_stepsread-onlySession 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.
eyes_resolve_checkpointMarks 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_pro…
eyes_resolve_regionsAdds/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 …
eyes_resolve_resetRestores 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 …
Show 7 more tools
eyes_resolve_saveSaves 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.
eyes_review_diff_reportRecords 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 r…
eyes_review_endRecords 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.
eyes_review_progressTracks 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 findi…
eyes_setup_projectGet 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.
eyes_setup_ufgConfigure 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.
eyes_verify_api_keyValidate 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.
Signals
- Stars
- 0
- Forks
- 0
- Open issues
- 0
- Weekly downloads
- 435
- Last commit
- Oct 20, 2026 (10 days ago)
- Last release
- Oct 25, 2026 (5 days ago)
- Last package publish
- Oct 19, 2026 (11 days ago)
From GitHub (fetched Oct 24, 2026) and the package registry.
Details
- Registry name
io.github.applitools/applitools- Version
- 1.0.9
- Auth
- No auth
- Packages
- npm @applitools/mcp
- License
- License unknown
- Repository
- github.com/applitools/mcp
- Website
- applitools.com
- First seen
- Oct 24, 2026
- Last checked
- Oct 26, 2026
Done for you
Rather not set it up yourself?
Chalk Labs scopes, builds and runs agents for your team: the task audit, the eval harness, the integrations and the weekly ops report. Fixed scope, priced before we start.
See how we build AI agents →Read the case studies
Chalk Labs is a two-founder AI and growth studio. We build AI agents, CRMs and MVPs for Web3 and AI companies, and have shipped 50+ product and token launches.
- launches shipped
- 50+
- launches shipped
- media placements
- 500+
- media placements
- founders on every account
- 2
- founders on every account
Press we've placed: Forbes · CoinDesk · Decrypt · Cointelegraph · The Block
Rahil Jain, Co-founder, Chalk Labs. Ex-Goldman Sachs engineer. You talk to the person who builds it.
Get Applitools running in your business
Tell us what you want to automate. A founder replies within one working day with a plan, not a pitch deck.
Cite this page
Applitools MCP server. Agent Mart. https://agentmart.dev/connectors/applitools-applitools (last updated 2026-10-26)