
Core
io.github.electron-stagewright由 GitHub 帳號 electron-stagewright 發布v0.8.1更新於 Oct 30, 2026
Agentic UX testing for real Electron apps: launch, inspect, interact, and assert through MCP.
發布方自己的服務:core.blue
概覽
讓 AI 助理啟動、檢視、操作並斷言真實 Electron 桌面應用程式的 MCP 伺服器,以無障礙樹快照為基礎。
- 可以做什麼
- 啟動、附加到或注入執行中的 Electron 應用程式,包括已開啟的開發伺服器
- 透過快照、差異、語意查找與完整元素狀態檢視無障礙樹
- 依穩定 ref 互動:點擊、輸入、等待複合狀態,並以可重試的 expect 斷言驗證行為
- 擷取螢幕截圖、主控台輸出、對話框與工作階段軌跡等診斷資訊
- 驗證已封裝簽章的發行產物,並視需要載入無障礙、視覺、IPC、網路、儲存與原生介面外掛
- 適用情境
- 當你希望助理端對端驅動或測試真實的 Electron 桌面應用程式時使用,包括瀏覽器自動化無法涵蓋的多視窗、原生選單與封裝建置檢查。適合 Electron 應用程式的代理式 UX 測試與除錯,而非一般網頁瀏覽。
- 執行需求
- 透過 npm 套件 @electron-stagewright/core 以 stdio 在本機執行。需要 Node.js 24 或更新版本,以及 Playwright 與 Electron 執行環境;Linux 上還需要顯示環境(DISPLAY、WAYLAND_DISPLAY 或 xvfb-run)。接入 MCP 主機前須先用 install-electron 預先取得 Electron 二進位檔並以 doctor 檢查。未宣告帳號或 API 金鑰。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Core,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
Electron Stagewright
[npm] [CI] [Real Electron E2E] [License: MIT]
Agentic UX testing for real Electron apps. Cue the app, prove the experience, and return bounded evidence through MCP.
Electron Stagewright is a Model Context Protocol (MCP) server that lets Claude Code, Codex, Cursor, Cline, Aider, and any MCP-compatible agent operate real Electron applications. Launch or attach, inspect the accessibility tree, interact through stable refs, assert behavior with retrying expectations, and capture diagnostics without turning every check into another agent round-trip.
Why this exists
Browser automation already has mature agent tooling. Electron adds a different boundary: the main process, renderer surfaces, native menus and dialogs, multiple windows, packaged runtimes, and signed release artifacts. A browser API exposed through MCP does not cover that whole product.
Electron Stagewright is designed agent-first from the primitive level up:
- Errors carry hints, suggested next actions, and similar-ref alternatives — agents recover without an extra round-trip asking for context.
- Every response reports its own token cost — agents budget in real time, not after the fact.
get_statereturns the full state envelope in one call — visible, enabled, checked, focused, disabled, aria-expanded, aria-busy, aria-invalid. No 4-call chain to decide if a button is clickable.wait_for_stateaccepts composite predicates —{ visible: true, enabled: true, focused: false }evaluated atomically by the server. One call replaces three.- Snapshots flag
recently_changedelements — agents focus reasoning on what differs from the last view instead of reprocessing the whole tree. - Snapshot diffs are a parameter, not a separate tool —
electron_snapshot({ since: 'last' })returns only deltas. Fewer APIs to remember. - Compact text encoding on demand —
electron_snapshot({ format: 'text' })renders one line per element ([3] textbox "Email" value="" focused) with only non-default state, cutting snapshot tokens 5-10x versus the JSON shape when the agent just needs to look. expect_*primitives replace read-compare-retry chains —electron_expect_text({ ref, equals: 'Welcome', timeoutMs: 5000 })is one call, not five.electron_findqueries the accessibility tree semantically —{ role: 'button', name_contains: 'Submit', visible: true }— no CSS selectors, no XPath, no guessing.- Hot-reload-aware — snapshot and find responses report when the renderer reloaded since the previous baseline, so agents know refs may need refreshing.
- Framework-agnostic snapshot — built on accessibility roles and ARIA instead of framework-internal properties. Current fixtures cover vanilla, React, Vue, and Angular; the broader renderer matrix is still expanding.
Electron-deep workflows
The server treats three Electron-specific workflows as first-class:
- Attach to a running dev server without restarting it.
electron_attachconnects to apps exposing a loopback CDP endpoint, andelectron_injectcan attach to a running main process via the Node Inspector handshake when no debug flag was arranged up front. - Session traces with deterministic replay and per-tool token budgets. Inspired by Playwright's
trace.zipbut designed for LLM agent sessions: a timeline of tool calls, arguments, results, timings, and token estimates — replayable against a fresh app instance, with budgets so agents can cap runaway loops. - End-to-end validation of signed, notarized, packaged
.appbundles —codesign, Gatekeeper assessment, autoUpdater feed inspection, URL-scheme declaration checks, and crash reporter machinery. The full production surface, not just dev.
Microsoft's official Playwright MCP team explicitly declined to support Electron ("you can release your own server for Electron" — Pavel Feldman, lead). This project takes the invitation seriously.
Quick start
Requires Node.js 24 or newer (node -v); on Linux the server also needs a display (DISPLAY,
WAYLAND_DISPLAY, or xvfb-run -a). The default launch transport uses Playwright and an
Electron runtime. For a private setup in the current project, keep the server local to that project
and pin the release-tested package set.
Before configuring an MCP host, prepare the same package set once in a terminal. Electron downloads
its binary the first time something loads it, not during install, and that download prints a
progress line to stdout; inside an MCP session the line would land in the protocol stream. Fetch the
binary with Electron's install-electron bin, then run doctor, which reports "ok": true and
exits 0 when every required check passes:
claude mcp list should then show the server as connected (or run /mcp inside a session), and
its tools appear as mcp__electron-stagewright__electron_launch and so on. Keep the --package
list identical across all three commands: npx caches each list separately, so adding the demo or
a plugin package means running install-electron and doctor again with the new list. Keep
--prefix ~/ too: without it, npx skips any listed package the current project already has at
that version (an Electron app often has both Playwright and Electron), and the server, which runs
from npx's cache, cannot load it. The server still runs in the current directory. To move to
a newer release later, follow
Update to a new release.
The default Claude Code scope is local: it is available only in the current project and stays out
of unrelated workspaces. To share a reviewed configuration with a team, use --scope project,
which writes the same mcpServers shape to .mcp.json. See the
Claude Code MCP scopes for the host-specific behavior.
To verify a host before pointing it at your app, add the pinned
@electron-stagewright/[email protected] package and use the demo guide. The demo
is opt-in, so a normal core installation neither loads nor depends on it.
For local development, build the checkout and point your MCP host at the built CLI:
Shared project .mcp.json shape:
Then from any MCP-compatible agent (tool names as Claude Code shows them; other hosts prefix them differently):
The full tool list — every tool, its parameters, and operation type — is in
TOOL-REFERENCE.md, generated from the live dispatcher manifest
(pnpm docs:tools).
Documentation
- Getting started — from a clean checkout to a complete driven session against the bundled example app.
- Try the packaged demo — verify a published MCP host setup against a local, multi-window Electron task board without supplying your own app path.
- Connect your MCP client — wire the published package into Claude Code, Codex, Claude Desktop, Cursor, VS Code, opencode, or any MCP host, confirm it connected, update it, or remove it.
- Launch, attach, or inject — getting a session against YOUR app, including apps that are already running.
- Assert UI state — refs vs selectors, the
expect_*family, waits, and snapshot diffs. - Type into code editors — the reliable Monaco / EditContext
typing path,
replace, the auto-pairing caveat, and how to verify the text landed. - Capture diagnostics — screenshots, console, dialogs, and session traces.
- Load, configure, and diagnose plugins — explicitly load plugins, grant
their narrowest gates, and inspect enabled tools and safe config with
electron_plugins. - Migrate from electron-driver — tool-by-tool mapping and the conceptual shifts.
- Choose an Electron MCP server — compare Electron automation workflows by capability, trust boundary, recovery evidence, and your own app.
- Compatibility — see which Node, Electron, operating-system, and transport combinations are verified by unit tests or real-runtime CI.
- Concepts — the agent-native model and why the server is shaped the way it is: the response envelope, refs, snapshots, retrying assertions, sessions, and the eval/plugin trust model, each linked to the decision that set it.
- Security model — the trust model, the controls behind
--allow-eval, and a deployment checklist. - Guides index · TOOL-REFERENCE.md · Architecture Decision Records.
Server flags
Pass these after the CLI path in your MCP host config (the args array). All default to the safe
option; diagnostics go to stderr (stdout is reserved for the JSON-RPC protocol channel).
The server exits 0 after a clean shutdown (SIGINT, SIGTERM, or the host closing stdin), 1 when
startup or shutdown teardown fails, and 2 for invalid usage such as an unknown flag.
Security defaults worth knowing when wiring this into another project: arbitrary JS (the
--allow-eval policy) and host-path launches (--app-root) are opt-in; electron_launch refuses
runtime-altering env vars (ELECTRON_RUN_AS_NODE, NODE_OPTIONS, LD_*, DYLD_*); and
user-supplied regex / text / key arguments are length- and complexity-bounded so a hostile tool call
cannot wedge the server.
Use --tool-profile essential when an agent needs the common launch, snapshot, interaction, wait,
and assertion workflow with a smaller initial manifest. Choose testing for the broader interaction,
read, and screenshot-evidence surface, or debug for attach, discovery, window, console, screenshot,
and dialog work.
full stays the default until the profile benchmark demonstrates equivalent task success with a
material context saving. See ADR-021 for the
measured budget policy.
What each response looks like (the agent-UX detail)
Success, for example from electron_expect_text:
Error:
The agent has everything to decide its next move without asking for context.
Architecture
Three transport implementations behind a single ITransport interface, so the project survives if Playwright's experimental _electron API changes or gets deprecated:
PlaywrightElectronTransport—_electron.launch(), fast path (default).CDPTransport— Chrome DevTools Protocol direct, no Playwright dependency; launches packaged executables through a managed loopback endpoint or attaches to an existing one, with iframe, webview andWebContentsViewsurface targeting plus snapshot/find, eval, observe, and interaction on the selected surface.InjectorTransport— Node Inspector handshake into a running process; supports main-process eval, window discovery, and console capture when an app was not started with a CDP endpoint.
Plugin model: a small core, with domain capabilities shipped as separate @electron-stagewright/plugin-* packages loaded explicitly via --plugin (the core never auto-scans). Shipped today: plugin-a11y (surface-scoped axe-core audits with bounded violations and incomplete checks; a fixed engine, not agent JavaScript, so no --allow-eval grant), plugin-visual (BrowserWindow visual baselines with explicit update confirmation, environment metadata, confined artifact roots, and actual/diff evidence), plugin-trace (session trace + deterministic replay + per-tool token budget), plugin-ipc (capture / invoke / stub Electron IPC, gated behind main eval: --allow-eval=main, or bare --allow-eval), plugin-production (validate packaged macOS, Windows, and Linux artifacts through MCP, a public library API, or a CI JSON CLI: bundle integrity, update/crash machinery, macOS signing/notarization/Gatekeeper, Windows Authenticode, and AppImage embedded signatures), plugin-network (renderer request/response capture, bodies, and stubbing via the transport seam), plugin-clock (deterministic renderer virtual time via the Playwright clock seam), plugin-storage (read, seed, and assert cookies, storage snapshots and per-key localStorage / sessionStorage through the no-eval transport seam, and IndexedDB records through a renderer-eval gate; cookie values are redacted by default, IndexedDB values can be redacted with config), and plugin-native-ui (read, assert, and invoke the application menu — the macOS menu bar — capture the notifications the app shows including startup ones, and read system-tray state plus fire tray events via launch-time instrumentation, all via the transport native-UI seam, no eval).
Dogfooding targets
The MCP is built against two real Electron applications maintained by the author, covering distinct verticals so the design doesn't accidentally bias to one shape:
- Code-editor shape — a code editor with runtime sandboxes, licensing, and IPC-heavy state. Stresses keyboard-driven flows, editor state, and license verification.
- POS shape — a multi-tenant Point of Sale desktop app with embedded Fastify server and SQLite. Stresses forms, large tables, embedded backend, auto-updater feeds.
If your Electron app has a shape these don't cover, open an issue — we'd love to add it as an example fixture.
Security
The server is a privileged local tool, not a sandbox: it drives a real app and, under an eval opt-in (--allow-eval or a target-specific variant), runs arbitrary JavaScript inside it, so only a trusted agent host should invoke it. The security model covers the trust boundaries, the controls (eval opt-in + blocklist, channel allowlists, launch confinement, structured redaction), and a deployment checklist; the posture is recorded in ADR-014. To report a vulnerability, see SECURITY.md.
Contributing
This project is in its earliest days. Issues and discussions welcome. See CONTRIBUTING.md for the workflow, and GOVERNANCE.md for how the project is run and the path to becoming a co-maintainer.
Selecting test projects
pnpm test and pnpm test:coverage select the ordinary unit project, retained across
all six OS/Node CI cells. pnpm test:real selects the serialized real-electron project
and checks actual JSON results against scripts/real-test-inventory.json (25 reviewed files,
36 scenarios). It refuses missing binaries/required native-addon fixture inputs and rejects
missing, skipped or zero execution on every platform. Prepare the native-addon inputs with
node scripts/prepare-native-addon-fixture.mjs and export the variables it prints (on Windows it
also fetches Electron's node.lib and points at npm's bundled node-gyp, which needs MSVC).
Packed CLI qualification stays separate.
License
MIT — see LICENSE.
來源:README.md,提交 bcc56bf
工具
0版本歷史
6- v0.8.1最新Oct 29, 2026
- v0.7.0Oct 25, 2026
- v0.6.3Oct 16, 2026
- v0.6.2Oct 16, 2026
- v0.6.1Oct 16, 2026
- v0.5.0Sep 16, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分
其他 Core 整合
core.blue
blue.core官方發布者
core.blue 的遠端 MCP 端點,提供每位客戶獨立的私有代理記憶「house」:可讀手冊、試用沙盒、查價格與建議,並申請 house。

Brevio Core
由 GitHub 帳號 Brevio-Ventures 發布
本機 MCP 伺服器,讓編碼代理掃描程式碼中反覆出現的代理式錯誤、解釋規則、列出規則,並把一次修正固化成守衛。

brain-core
由 GitHub 帳號 xy-claude 發布
本機 MCP 伺服器,為 Claude Code 代理提供跨工作階段的長期記憶,以 markdown 檔案加上本機 SQLite 與向量索引保存。

Scovant Core
由 GitHub 帳號 Scovant 發布
對網站進行被動式AI代理就緒掃描:robots、llms.txt、JSON-LD、MCP發現、安全性。AI 翻譯

ProofCore
由 GitHub 帳號 ProofCore-Protocol 發布
面向AI代理的TON區塊鏈零認證加密公證與證據層。AI 翻譯