A development-intelligence layer for Electron - IPC scaffolding, security audits, build-error diagnosis and version migration, from Claude Code, Cursor, or any MCP client.
@yawlabs/electron-mcp makes your AI assistant actually good at Electron. It covers the parts models reliably hallucinate about: context isolation, preload bridges, fuses, CSP, code signing, auto-updates, breaking changes between majors, and the official security recommendations. This is not a runtime debugger - it is a development-intelligence layer that turns "write me some Electron code" from hit-or-miss into correct-on-the-first-try. Built and maintained by Yaw Labs, MIT licensed, published on npm.
npx -y @yawlabs/electron-mcp@latestGitHub · npm · Add to Yaw MCP
Anyone shipping an Electron app with an assistant in the loop. Other Electron MCP servers give your model a shell and hope; this one gives it structured answers about Electron itself, so the code it writes is secure by construction rather than by review:
contextBridge exposure, TypeScript types and renderer usage. No nodeIntegration: true, no raw ipcRenderer bolted onto window.1. No API key, no environment variables. There is nothing to provision. Skip straight to the config.
2. Add the server to your client. On macOS, Linux and WSL, a .mcp.json in your project root:
{
"mcpServers": {
"electron": {
"command": "npx",
"args": ["-y", "@yawlabs/electron-mcp@latest"]
}
}
}On Windows, wrap the call in cmd /c: npx is a .cmd file there, and since Node 20 child_process.spawn cannot execute .cmd files directly.
{
"mcpServers": {
"electron": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@yawlabs/electron-mcp@latest"]
}
}
}3. Restart and approve. Restart Claude Code (or your MCP client) and approve the Electron MCP server when prompted. Then ask it something: "Audit my BrowserWindow config for security issues - here's my main.ts and preload.ts."
The same JSON block works in every client; only the config file moves:
| Client | Config file |
|---|---|
| Claude Code | .mcp.json (project root) or ~/.claude.json (global) |
| Claude Desktop | ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) |
| Cursor | ~/.cursor/mcp.json |
| Windsurf | ~/.codeium/windsurf/mcp_config.json |
| VS Code | .vscode/mcp.json |
Running Yaw MCP? One click adds it to your local config, and it is then available in every Yaw Terminal session.
| Area | What it covers |
|---|---|
| IPC and process architecture | Scaffold a complete IPC round trip, generate a secure preload bridge for multiple API methods, audit preload/main/renderer code for IPC problems (direct ipcRenderer, missing sender validation, channel injection), generate a multi-window manager, and explain the multi-process model for your version |
| Security | Audit against the official security recommendations, generate an @electron/fuses block for production hardening, generate a bundler- and framework-aware CSP, and lint for dangerous patterns such as shell.openExternal on untrusted input, @electron/remote and enableBlinkFeatures |
| Build and distribution | Diagnose electron-builder and forge failures (Apple and Windows code signing, native module rebuilds, ASAR packaging, entitlements, path quoting), generate an electron-updater setup, register custom protocols for deep linking across platforms, and scaffold a secure modern project |
| Migration and compatibility | A migration checklist between Electron versions with breaking changes, deprecated APIs and platform support changes, plus a scan of your source for APIs deprecated or removed in the target version |
| Performance | Detect the official Electron performance anti-patterns - synchronous I/O on the main process, unbounded event listeners and the rest |
| Reference | Authoritative explainers for the process model, context isolation, sandbox, IPC, ASAR, fuses, code signing and build tools, plus electron_knowledge_version for the embedded knowledge metadata |
The security audit is worth calling out for what it does not claim: it checks the official recommendations that can be verified from static inputs - BrowserWindow config, preload, CSP, remote content, sandbox. Session permission handling needs runtime context, cannot be judged from source alone, and is flagged in the report footer rather than quietly scored as a pass.
An Electron advice tool is only as good as the day its knowledge was written, so this one declares that date instead of assuming it. Every response from a knowledge-backed tool - breaking changes, deprecated APIs, security recommendations, anti-patterns, concept explainers - carries a footer in this shape:
_Knowledge last verified YYYY-MM-DD (Electron vN stable)_Call electron_knowledge_version to get that metadata directly, including the supported version range - useful when an agent is unsure whether its advice still applies. If your Electron is newer than the footer, the tool says so rather than answering confidently from stale knowledge.
readOnlyHint, destructiveHint: false and idempotentHint: true, so clients can skip confirmation. The tools never touch your filesystem, never run code and never call exec.node_modules install on first spawn and no electron or electron-builder pulled into your project to inflate it. The published package's dependencies is empty. Worth knowing if you audit the repo: Dependabot alerts there are against devDependencies - the MCP SDK's optional HTTP transport surface - which the bundle does not include, because this server is stdio only.electron_knowledge_version first. If Electron has shipped a new major since the verified date, cross-check the official breaking-changes page linked there, then file an issue with the tool, version, and expected versus actual. Knowledge updates ship in minor versions.cmd /c npx ... form above. Node 20 and later cannot spawn .cmd files directly.It is a development-intelligence layer, not a runtime debugger. It gives your assistant tools for the parts of Electron that models tend to hallucinate: context isolation and preload bridges, fuses, CSP, code signing, auto-updates, breaking changes between majors, and the official security recommendations. The goal is turning write me some Electron code from hit-or-miss into correct on the first try.
No. There are no API keys and no environment variables. Add the server to your client config, restart, approve it, and start asking questions. It ships as a single bundled file with zero runtime dependencies, so there is no multi-minute install before the first call.
No. Every tool declares readOnlyHint, destructiveHint false and idempotentHint true, so MCP clients can skip confirmation on them. The tools never touch your filesystem, never run your code and never call exec. Generated scaffolds, audits and configs come back as text for you or your assistant to apply.
Freshness is declared rather than assumed. Every response from a knowledge-backed tool carries a footer naming the date the knowledge was last verified and the Electron stable release at that time, and electron_knowledge_version returns that metadata directly along with the supported version range. If your Electron is newer than the footer, the tool tells you so you can cross-check the official breaking-changes page.
Any client that speaks MCP. The same JSON block works in Claude Code, Claude Desktop, Cursor, Windsurf and VS Code; only the path to the config file differs. On Windows, wrap the call in cmd slash c, because npx is a .cmd file there and Node 20 and later cannot spawn .cmd files directly.
Published by Yaw Labs.