Labsco
MCP SERVER

Electron Driver

by mesomya

Drive a compiled Electron app — clicks, real keystrokes, drags, dialogs and the main process — using numbered refs instead of guessed selectors.

Browser Automation, Control & ScreenshotsVerified
Summary
The ref system is what separates this from a generic browser driver: snapshot returns numbered handles, so the guess-a-selector-and-retry loop never starts.

The ordering is strict and the tools say so themselves — start_app before anything, snapshot before interacting — which is unusual candour for a driver and saves the first hour of confusion. The pairs that look redundant are the ones worth reading twice: type fills a value while keyboard_type dispatches real key events for editors that only listen to keydown, and set_input_files is named as the correct path for upload testing while drop_file states that it does not populate file.path, pushing apps that rely on webUtils.getPathForFile toward eval_main. press_sequence is an alias of keyboard_type kept for backwards compatibility, so new work has a single obvious choice.

What it is

A Playwright-backed driver for a compiled Electron app: launch it, read the screen as ref-numbered structure, act through trusted input events, and evaluate JavaScript in the renderer or the main process.

What you get
  • A session with a defined beginning and end: start_app launches the app from the absolute path to its compiled main-process entry, taking args, cwd, env, executablePath, screenshotsDir and timeoutMs and wiping the screenshots directory on each fresh start, and stop_app closes it cleanly whether or not an app is running.
  • Screen reading that removes the selector-guessing round trip: snapshot returns the visible page with a [ref] number on every interactive or labelled element, and those refs go to click, type, hover and get_text in place of selectors; accessibility_snapshot returns the accessibility tree as JSON; elements_list enumerates matches with tag, text snippet, id, attributes and bounding box; focused_element reports what currently holds focus.
  • Input that reaches the code actually listening: click takes a selector or a ref with button, clickCount, position and force; type fills through Playwright's fill; keyboard_type dispatches per-character keydown, keypress and keyup so CodeMirror and contenteditables respond; press sends a key or chord such as Control+Shift+P; drag moves through real Chromium input events so PointerEvents fire as they would for a person.
  • Form controls driven directly: select_option picks by value, label or zero-based index; check and uncheck toggle a checkbox or radio and no-op when it already holds that state; clear_input empties an input or textarea; set_input_files puts files on an input of type file without opening the native picker.
  • Waiting that is specific rather than a sleep: wait_for_selector waits for attached, detached, visible or hidden and hands back the element count and the first match's bounding box; wait_for polls a JavaScript predicate in the renderer until it returns truthy and yields its value; wait pauses for a fixed number of milliseconds.
  • Reads to assert against: get_text, get_value, get_attribute, get_bbox and get_computed_style return text, input values, attributes, geometry in CSS pixels and named computed CSS properties; exists returns a match count without waiting; info returns window title, URL, viewport size, uptime and devicePixelRatio.
  • Scrolling and dropping: scroll moves an element or the window to an absolute x and y or by a dx and dy delta, scroll_into_view brings a match into view, and drop_file dispatches synthetic drag-and-drop with a DataTransfer carrying the file's contents.
  • Windows and dialogs handled without a human: windows_list reports every BrowserWindow with title, URL, id and focused, minimized or maximized state; switch_window routes subsequent calls to another window by index or titleMatch; dialog_handler installs an auto-responder that accepts or dismisses alert, confirm, prompt and beforeunload.
  • Reaching past the page: eval_renderer runs a function body in the renderer, eval_main runs a function body in the Electron main process with the full electron module and your arg in scope, and console_logs returns renderer console output alongside main-process stdout and stderr, draining the buffer when asked.
  • Evidence from the run: screenshot captures a full-page PNG and returns its absolute path, and cleanup_screenshots empties the session directory between phases.
Requirements

A compiled Electron app on disk, addressed by the absolute path to its main-process entry such as out/main/index.js, and a start_app call before any other tool will drive it. No credentials are configured.

Setup effort

One command — npx electron-driver