Search for one and you get two different products wearing the same name. Here is the split, what each side cannot do, and how to pick.
Search npm or GitHub for "electron mcp server" and you will find a dozen projects. Almost all of them do the same thing: attach to a running Electron app over Chrome DevTools Protocol or Playwright, then let the model click buttons, screenshot windows, read the console and evaluate JavaScript. Ours, npx -y @yawlabs/electron-mcp, does none of that. It never launches your app. The distinction is worth twenty minutes of your time before you install either kind, because they solve problems that do not overlap at all.
Runtime drivers answer questions about a running app. Why is this button dead, what did the renderer log, does this window look right, can you walk the app through a login flow. They need the app running and reachable, and they are the correct tool for end-to-end testing and live debugging.
Development intelligence answers questions about the code. Is this preload script safe, what does a correct IPC round-trip look like in the current Electron, which of my APIs disappear if I go from 32 to 41, why is electron-builder failing with this signing error. It needs no running app and cannot tell you anything about runtime behaviour.
Both are legitimate. The failure mode is installing one and expecting the other -- asking a CDP driver to review your contextIsolation settings, or asking ours why your app crashed on launch.
One thing neither category has: an official implementation. As of September 2026 the Electron project's GitHub organisation publishes no MCP server, and none of the projects below is endorsed by it. They are all community or vendor work, so read the repository before you trust the tool.
Electron is unusually hostile to a model's training data. The security posture inverted over several majors: nodeIntegration went from normal to forbidden, contextIsolation defaulted to off and has defaulted to on since Electron 12, remote was removed from core in Electron 14 and moved to a separate package, and sandboxing became the default in Electron 20. A model that has absorbed a decade of tutorials will cheerfully hand you a 2017-shaped webPreferences block that works perfectly and is wide open.
So the useful thing to give a model is not a shell. It is current, structured knowledge with a date on it.
Eighteen tools, version 1.4.1, MIT, and the published package has no runtime dependencies at all -- it is a single bundled file, so adding it does not drag a tree of transitive packages into your environment. The split is five IPC and process-architecture tools, four security, four build and distribution, two migration, one performance, one reference explainer, and one that reports the vintage of its own knowledge.
Every one of the eighteen declares readOnlyHint and destructiveHint: false, which is not a marketing line but a protocol annotation your client can act on: none of these tools writes a file, runs a command, or opens a socket. They take code as an argument and return text.
The two that earn their keep most often:
electron_scaffold_ipc_channel generates the whole round-trip at once -- main-process handler, typed preload bridge, contextBridge exposure, and renderer usage -- so the model does not get to improvise the part where it decides to put ipcRenderer on window.
electron_audit_security runs 19 static checks derived from Electron's own security checklist, which has 20 numbered recommendations. The checks cover HTTPS-only content, nodeIntegration, contextIsolation, sandbox, webSecurity, CSP, insecure-content and experimental flags, raw ipcRenderer exposure, @electron/remote, Electron version currency, shell.openExternal validation, file:// usage, <webview>, navigation and window-open handlers, and IPC sender validation. Two checklist items cannot be judged from source alone -- session permission request handling, and which fuses your packaged build flips -- and the report says so in its own footer rather than quietly scoring them as passes.
Alongside those: electron_configure_fuses and electron_configure_csp generate the hardening config that the audit cannot infer, electron_migrate_version and electron_check_deprecated_apis handle major bumps, electron_diagnose_build_error parses electron-builder and Forge output, and electron_audit_performance checks source against seven anti-patterns drawn from Electron's performance guide -- eager module loading, synchronous main-process calls, too many windows at startup, pointless polyfills, CDN-loaded assets, heavy preloads, and unbundled dependencies. We wrote about what that audit found in our own app, which is where several of those patterns came from.
> "Add a file picker that lets the renderer read the file"
-> electron_scaffold_ipc_channel({ channelName: "open-file",
direction: "renderer-to-main", returnType: "string",
description: "Pick a file and return its contents" })
main handler + preload bridge + types + renderer usage
> "We're on 32. What breaks if we jump to 41?"
-> electron_migrate_version({ currentVersion: 32,
targetVersion: 41 })
breaking changes per major, APIs deprecated or removed
across that range, platform support changesEvery knowledge-backed response ends with a footer naming when the embedded data was last verified, and electron_knowledge_version returns that metadata directly. At the time of writing, the repository pins it at 2026-04-13, Electron v41 stable, supported range v28 to v41.
Electron stable is 44.3.0 as of 8 September 2026. So the embedded knowledge is three majors behind, and a migration question that targets 42, 43 or 44 is outside the range it claims to cover. The design point is that the server tells you this instead of confidently inventing an answer -- a stale fact that announces its own staleness is recoverable, and a stale fact delivered in the same confident voice as a fresh one is not. But it is a real gap, and if your bump is 41 to 44 you should read Electron's breaking-changes page yourself rather than trusting the tool.
All three declare MIT in their own repositories, read in September 2026 -- though marcusdb/mcp-electron states it in its package.json and README rather than in a LICENSE file.
| Capability | @yawlabs/electron-mcp |
@laststance/electron-mcp-server | @kanishka-namdeo/electron-mcp-server | marcusdb/mcp-electron |
|---|---|---|---|---|
| Category | Development intelligence | Runtime driver | Runtime driver | Runtime driver |
| Drives a live app | No | Attaches over CDP to an app you started | Launches it, or attaches over CDP | Launches it via Playwright |
| Click, type, screenshot, read console | No | Yes | Yes | Yes |
| Generates IPC / preload / contextBridge code | Yes | No | No | No |
| Audits against the official security checklist | 19 static checks | No | No | No |
| Version-migration knowledge | v28-v41 embedded | No | No | No |
| Build-error diagnosis (signing, ASAR, native modules) | Yes | No | No | No |
| Setup requirement | None | App started with a remote debugging port | Playwright launches the app, or a CDP endpoint to attach to | Playwright; nodeCliInspect fuse must not be disabled |
| Runtime dependencies | None (bundled) | Playwright, Electron, ws | Playwright, pino | Playwright |
| Version read | 1.4.1 | 2.0.1 | 1.0.4 | 0.0.1, source only (not on npm) |
They can actually run your app, and we cannot. This is not a small gap, it is most of the debugging you do. If the question is "the export button does nothing on Windows", a CDP driver attaches, reproduces it, reads the console error and the failed network call, and screenshots the state. Ours will confidently discuss your IPC design while the bug sits in a renderer it has never seen. For end-to-end tests, visual regression, or any "reproduce it and show me", a runtime driver is the right tool and we are the wrong one.
@laststance/electron-mcp-server talks CDP over a WebSocket and will scan the usual debugging ports to find your app, which makes attaching to an already-running instance straightforward. It covers UI interaction, page structure inspection, arbitrary JS evaluation, log reading and window info, plus launching and building the app.
@kanishka-namdeo/electron-mcp-server is the broadest of the three by its own accounting -- its README describes 44 tools across app lifecycle, element interaction, main-process and window control, visual testing and accessibility, advanced CDP features, and codegen. If you want accessibility snapshots and recorded test generation, this is the one to read first.
marcusdb/mcp-electron takes the most reusable approach: it extends the official Playwright MCP server to Electron, so if your team already writes Playwright tests, the concepts and much of the tool surface carry straight over. Its README also lists video recording and trace collection. It is by some distance the earliest-stage of the three, though: version 0.0.1, no published npm package, so you install it from source, and the last commit was May 2025. Read it for the approach, and check it still builds before you depend on it.
One caveat that applies to the whole driver category, and it is theirs to state rather than ours: these tools want the runtime features that production hardening removes. mcp-electron's README asks that the nodeCliInspect fuse not be disabled, and CDP drivers need a debugging port open. That is entirely reasonable for a development build -- it is just worth knowing that the app you drive and the app you ship should not be the same binary.
webPreferences.Add it to any MCP client, or let Yaw MCP fan one config out to every client on the machine:
npx -y @yawlabs/electron-mcpSource: github.com/YawLabs/electron-mcp, and the server card is on our MCP servers page.
Two different things, depending on which one you install. Most of them are runtime drivers: they attach to a running Electron app over Chrome DevTools Protocol or Playwright and let the model click elements, take screenshots, read console output and evaluate JavaScript. A smaller category is development intelligence: the server carries Electron-specific knowledge and answers questions about your source, such as generating a contextBridge preload, auditing a BrowserWindow config against the official security checklist, or listing what breaks between two Electron majors.
No. As of September 2026 the Electron project's own GitHub organisation publishes no MCP server, and Electron's documentation does not name one. Every Electron MCP server available today is a community or vendor project, so judge each on its own repository rather than on an assumption of official status.
Yes, but you need a runtime driver rather than a development-intelligence server, and the app has to be launched so the driver can attach. The CDP-based drivers expect a remote debugging port such as 9222; the Playwright-based ones launch the app themselves. Note that these generally target development builds, because a fully hardened production build disables the very runtime features a driver relies on.
Jeff Yaw, Yaw Labs. Follow along at tokenlimit.news for weekly notes on AI infrastructure.
Published by Yaw Labs.