Provides tools for Electron app development: IPC scaffolding, security auditing, migration guidance, performance analysis, and more.
Provides tools for diagnosing electron-builder/forge build errors, configuring auto-updates, and managing code signing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@yawlabs/electron-mcp Audit my Electron security settings"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Make your AI assistant actually good at Electron. 18 tools for the stuff AI models hallucinate about: context isolation, preload bridges, fuses, CSP, signing, auto-updates, breaking changes between majors, and the 20 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.
One click adds this to your local Yaw MCP config so it's available in every Yaw Terminal session. Or install manually below.
Other Electron MCP servers give your model a shell and hope. This one doesn't.
IPC that isn't a security hole — electron_scaffold_ipc_channel generates main handler + typed preload bridge + contextBridge exposure + renderer usage in one call. No nodeIntegration: true, no direct ipcRenderer on window.
The official security recommendations, enforced — electron_audit_security checks your BrowserWindow config, preload scripts, and CSP against 19 of the 20 items from electronjs.org/docs/latest/tutorial/security that can be verified from static inputs. (The 20th, session permission handling, needs runtime context and is flagged in the report footer.) Not a vibe check.
Version-aware migration — electron_migrate_version knows the breaking changes from v28 through v41 and tells you exactly what will break when you bump. electron_check_deprecated_apis scans your code for APIs that were removed.
Build errors, explained — electron_diagnose_build_error parses electron-builder/forge output and identifies root causes: Apple signing, Windows code signing, native module rebuilds, ASAR packaging, entitlements, path quoting.
Modern production hardening — electron_configure_fuses generates the @electron/fuses block for disabling unused runtime features (cookie encryption, Node CLI flags, legacy load behaviour). electron_configure_csp generates a CSP that actually works with your bundler and framework instead of blocking your own assets.
Knowledge freshness is declared, not assumed — every response includes a _Knowledge last verified YYYY-MM-DD (Electron vN stable)_ footer. Call electron_knowledge_version to get the metadata directly. If your Electron is newer than the footer, the tool tells you.
Read-only, no side effects — every tool declares readOnlyHint, destructiveHint: false, idempotentHint: true, so MCP clients can skip confirmation. The tools never touch your filesystem, never run code, never call exec.
Zero runtime dependencies — ships as a single bundled file. No 5-minute node_modules install, no electron or electron-builder installed as dependencies to inflate your project. The published package's dependencies is {}; Dependabot alerts on this repo are against devDependencies (the MCP SDK's optional HTTP transport surface) which the bundle doesn't include — this server uses stdio only.
Related MCP server: DevToolkit MCP Server
No API keys. No environment variables. Just install it.
1. Create .mcp.json in your project root
macOS / Linux / WSL:
{
"mcpServers": {
"electron": {
"command": "npx",
"args": ["-y", "@yawlabs/electron-mcp@latest"]
}
}
}Windows:
{
"mcpServers": {
"electron": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@yawlabs/electron-mcp@latest"]
}
}
}Why the extra step on Windows? Since Node 20,
child_process.spawncannot directly execute.cmdfiles (that's whatnpxis on Windows). Wrapping withcmd /cis the standard workaround.
2. Restart and approve
Restart Claude Code (or your MCP client) and approve the Electron MCP server when prompted.
That's it. Now ask your AI assistant:
"Add a file picker to my Electron app"
"Audit my BrowserWindow config for security issues"
"My electron-builder is failing with a signing error — here's the output"
"Generate a CSP for my Vite + React renderer"
"What breaks if I upgrade from Electron 32 to 41?"
Client | Config file |
Claude Code |
|
Claude Desktop |
|
Cursor |
|
Windsurf |
|
VS Code |
|
Use the same JSON block shown above in any of these.
electron_scaffold_ipc_channel — Generate a complete IPC round-trip: main handler, preload bridge, contextBridge exposure, TypeScript types, renderer usage.
electron_generate_preload_bridge — Generate a secure preload.ts with contextBridge for multiple API methods.
electron_audit_ipc_security — Analyze preload/main/renderer code for IPC security issues (direct ipcRenderer, missing sender validation, channel injection).
electron_generate_window_manager — Multi-window management with lifecycle tracking and inter-window communication.
electron_explain_process_model — Version-aware explanation of Electron's multi-process architecture (main vs renderer vs utility, what lives where).
electron_audit_security — Audit against 19 of the 20 official security recommendations that can be detected from static inputs: BrowserWindow, preload, CSP, remote content, sandbox. (Session permission handling is the 20th; it needs runtime context and is flagged in the report footer.)
electron_configure_fuses — Generate @electron/fuses config for production hardening (disable cookie encryption fallback, Node CLI flags, legacy load behaviour).
electron_configure_csp — Generate a Content Security Policy aware of your bundler (Vite/webpack/Parcel) and framework (React/Vue/Svelte).
electron_lint_security — Static analysis for dangerous patterns: shell.openExternal with untrusted input, @electron/remote, enableBlinkFeatures, etc.
electron_diagnose_build_error — Parse electron-builder/forge errors and identify root causes: code signing, native modules, ASAR, entitlements, path quoting.
electron_configure_auto_update — Generate complete electron-updater setup with events and platform-specific signing concerns.
electron_configure_deep_linking — Custom protocol registration across Windows/macOS/Linux.
electron_scaffold_project — Generate a secure, modern Electron project scaffold (contextIsolation: true, sandbox: true, preload, TypeScript, chosen framework).
electron_migrate_version — Migration checklist between Electron versions with breaking changes, deprecated APIs, platform support changes.
electron_check_deprecated_apis — Scan source for APIs deprecated or removed in the target Electron version.
electron_audit_performance — Detect the 8 official Electron performance anti-patterns (sync I/O on main, unbounded event listeners, etc).
electron_explain_concept — Authoritative explainer for 8 topics: process model, context isolation, sandbox, IPC, ASAR, fuses, code signing, build tools.
electron_knowledge_version — Metadata about the embedded knowledge: last-verified date, Electron stable at verification, supported version range. Call this if an agent is unsure whether advice is current.
Tools that depend on embedded Electron knowledge (breaking changes, deprecated APIs, security recommendations, anti-patterns, concept explanations) append a footer like:
_Knowledge last verified 2026-04-13 (Electron v41 stable). For anything newer, check https://releases.electronjs.org._Call electron_knowledge_version to get the metadata directly. When a new Electron major releases, KNOWLEDGE.md documents the update process.
> "Add a file picker that lets the renderer read the selected file's contents"
→ electron_scaffold_ipc_channel({
direction: "renderer-to-main",
channel: "open-file",
returns: "string"
})
# Generates: main handler (dialog.showOpenDialog + fs.readFile),
# preload bridge (contextBridge.exposeInMainWorld),
# TypeScript types for window.api.openFile,
# renderer usage example> "Check my Electron app for security issues — here's my main.ts and preload.ts"
→ electron_audit_security({ mainCode: "...", preloadCode: "..." })
# Returns a graded report against 19 of 20 recommendations
# (session permissions needs runtime context),
# flagging nodeIntegration, missing contextIsolation,
# unsandboxed renderers, loose CSP, and more.> "electron-builder is exiting with: errSecInternalComponent — help"
→ electron_diagnose_build_error({ output: "..." })
# Identifies macOS Keychain Access issue with code signing,
# returns specific `security` CLI fix and CI reconfiguration.> "We're on Electron 32. What breaks if we jump to 41?"
→ electron_migrate_version({ from: 32, to: 41, sourceCode: "..." })
# Returns breaking changes across each major (33, 34, 35, ...),
# deprecated APIs found in your code,
# platform support changes,
# recommended test plan.> "Generate a CSP for my Vite + React renderer that actually works"
→ electron_configure_csp({
bundler: "vite",
framework: "react",
allowedOrigins: ["https://api.mycompany.com"]
})
# Returns a CSP that accounts for Vite's dev-mode WebSocket,
# React's inline runtime, and blocks everything else."Tool output is cut off / too long"
A few scaffolders produce >10KB of generated code. Ask the assistant to regenerate with a narrower scope (single channel vs multi-channel bridge; one framework scaffold vs comparison).
"The advice is wrong for my Electron version"
Check electron_knowledge_version. If Electron has shipped a new major since the verified date, cross-check with the official breaking-changes page linked there.
File an issue on the repo with the specific tool + version + expected vs actual. Knowledge updates ship in minor versions.
"Windows: MCP server doesn't start"
Use the cmd /c npx ... pattern from the Quick start section. Node 20+ can't spawn .cmd files directly.
Node.js 20.11+
No runtime dependencies
git clone https://github.com/YawLabs/electron-mcp.git
cd electron-mcp
npm install
npm run lint # Biome check
npm run lint:fix # Auto-fix
npm run build # tsc + esbuild bundle
npm test # node --testSee CONTRIBUTING.md for the full workflow, including release process.
MIT
Analyze preload script and main process IPC code for security issues. Checks for: raw ipcRenderer exposure, missing sender validation, synchronous IPC usage, listener memory leaks, prototype pollution via contextBridge, and insecure channel patterns. Provide the actual code content to analyze.
| Name | Required | Description | Default |
|---|---|---|---|
| mainCode | No | Content of the main process IPC handler code to analyze | |
| preloadCode | No | Content of the preload script (preload.ts/js) to analyze | |
| rendererCode | No | Content of renderer code that uses IPC, to check for anti-patterns |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent behavior; the description confirms analysis purpose and adds transparency by listing specific security checks (e.g., raw ipcRenderer exposure, missing sender validation), going beyond annotation detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second details checks and instruction. No extraneous content, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and no output schema, the description adequately states inputs and checks but omits output format (e.g., list of issues, pass/fail). For a security audit tool, this leaves some uncertainty about what the agent receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter (preloadCode, mainCode, rendererCode). The description reinforces that code content is needed but adds no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes preload scripts and main process IPC code for security issues, listing specific checks. This distinguishes it from siblings like electron_audit_security (general) and electron_lint_security (linting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to provide actual code content, implying usage context, but lacks explicit guidance on when to use this tool versus alternatives like electron_audit_security or electron_lint_security.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze Electron app code for 7 official performance anti-patterns: eager module loading, synchronous main-process operations, excessive BrowserWindows at startup, unnecessary polyfills, CDN-loaded assets, heavy preload scripts, and unbundled dependencies. Returns specific fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| mainCode | No | Main process code to analyze | |
| packageJson | No | package.json content to check for bundling and dependencies | |
| preloadCode | No | Preload script code to analyze | |
| rendererCode | No | Renderer process code to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by listing the 7 anti-patterns and stating 'Returns specific fixes,' which informs the agent about output and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and explicitly lists the anti-patterns. No redundant information; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers all parameters and the description specifies the output (fixes), the tool is explained well. However, it lacks details on error handling, behavior with empty input, or return format specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented there. The description does not add additional meaning beyond the schema, remaining generic. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes Electron app code for 7 specific performance anti-patterns, listing them. It distinguishes from sibling tools like electron_audit_security by specifying performance focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for performance issues but does not explicitly state when to use versus alternatives like security or migration tools. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit an Electron app against the official security checklist. Covers 19 of the items that can be detected from static inputs (BrowserWindow configuration, main process code, package.json, preload, HTML): HTTPS-only content, nodeIntegration, contextIsolation, sandbox, webSecurity, CSP, allowRunningInsecureContent, experimentalFeatures, enableBlinkFeatures, raw ipcRenderer exposure, direct window assignment, @electron/remote, supported Electron version, shell.openExternal validation, file:// usage, tag, will-navigate handler, setWindowOpenHandler, and IPC sender validation. The remaining checklist items (session permissions, fuse configuration) require runtime / packaging context and are flagged in the report's footer.
| Name | Required | Description | Default |
|---|---|---|---|
| mainCode | No | Main process code -- used to detect non-HTTPS URLs in loadURL/loadFile calls | |
| htmlContent | No | Content of the main HTML file to check CSP meta tags | |
| packageJson | No | Content of package.json to check Electron version and dependencies | |
| preloadCode | No | Content of the preload script | |
| electronVersion | No | Electron major version if not in package.json (e.g. '41') | |
| browserWindowConfig | No | BrowserWindow constructor options as a JSON string or code snippet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) are fully consistent with the description, which adds valuable detail: the tool performs static analysis, covers 19 items, and flags remaining items in the report footer. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and then lists covered items. While somewhat long, each sentence adds value. Could be slightly more concise, but structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions a 'report' and 'footer' but does not detail the output format. Parameters are well-covered by schema. For a complex audit tool, it provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context by explaining how each input (e.g., mainCode for detecting non-HTTPS URLs) contributes to the audit, going beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits an Electron app against the official security checklist, listing 19 specific items it covers. It distinguishes itself from sibling tools (e.g., electron_audit_ipc_security) by focusing on the full static security audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists what is covered (19 static items) and what is not (runtime/packaging items, flagged in footer), providing clear context for when to use. However, it does not directly mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan code for usage of deprecated or removed Electron APIs. Returns a list of deprecated APIs found with their replacements and the version they were deprecated/removed in.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code to scan for deprecated API usage | |
| electronVersion | No | Current Electron major version to determine what's deprecated (default: 41) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent. The description adds that it scans code (reads input) and returns a list, which is consistent and provides additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence states action and output, second specifies the return structure. Extremely concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema), the description covers the return format adequately. It tells what the tool returns without needing an output schema. Good completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented in the schema. The description adds no extra parameter-specific detail, which is acceptable given high coverage. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans source code for deprecated or removed Electron APIs and returns a list with replacements and deprecation version. This distinctively separates it from siblings like security or performance audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking deprecated APIs before migration or cleanup. It doesn't explicitly exclude other tools, but the task is well-scoped. A slight improvement would be adding 'Use this before migrating your Electron version.', but it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate complete auto-update configuration using electron-updater. Produces main process setup, update event handling, renderer notification UI code, and platform-specific signing requirements. Supports GitHub releases, S3, and generic HTTP update servers.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Update distribution method: 'github' (GitHub Releases), 's3' (AWS S3), 'generic' (any HTTP server) | |
| s3Bucket | No | S3 bucket name (for 's3' provider) | |
| genericUrl | No | Base URL for updates (for 'generic' provider) | |
| githubRepo | No | GitHub repo name (for 'github' provider) | |
| githubOwner | No | GitHub owner (for 'github' provider) | |
| autoDownload | No | Automatically download updates (default true) | |
| autoInstallOnQuit | No | Install update on app quit (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims it 'produces' code, implying state mutation (generating/modifying files), but annotations set readOnlyHint=true, indicating no modification. This is a direct contradiction. Also fails to disclose potential side effects like overwriting existing files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded, no redundant information. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description explains output (code for main process, UI, signing), compensating for lack of output schema. However, contradiction reduces completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no additional meaning beyond parameter descriptions. Mentions provider types in summary but does not elaborate on each parameter beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates auto-update configuration using electron-updater, specifying what it produces (main process setup, event handling, UI code, signing requirements) and supported providers. Distinct from sibling tools focused on auditing, migration, or scaffolding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, but sibling tools are all different, so context is implicitly clear. Lacks prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Content Security Policy for an Electron app. Accounts for the bundler (Vite, webpack), framework (React, Vue, Svelte), and whether dev-mode exceptions are needed. Returns both meta-tag and session.webRequest approaches.
| Name | Required | Description | Default |
|---|---|---|---|
| bundler | No | Bundler used (affects script-src for HMR in dev mode). Defaults to 'vite'. | |
| needsEval | No | Whether eval() is needed (some template compilers). Defaults to false. | |
| externalImages | No | External origins for images, e.g. ['https://cdn.example.com'] | |
| needsInlineStyles | No | Whether inline styles are required (e.g. CSS-in-JS). Defaults to false. | |
| externalConnections | No | External origins the app connects to, e.g. ['https://api.example.com', 'wss://ws.example.com'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, etc. The description adds beyond that by explaining it returns both meta-tag and session.webRequest approaches, and accounts for bundler, framework, and dev-mode exceptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence states the main purpose, the second adds key details (output formats and considerations).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and no output schema, the description adequately explains the tool's purpose and output approaches. However, it could be more specific about how parameters affect the generated policy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning to parameters beyond what the schema already provides; it focuses on output approaches.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource 'Content Security Policy for an Electron app', and distinguishes from sibling tools like electron_audit_security by specifying it accounts for bundler, framework, and dev-mode exceptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (Electron app, need CSP) but does not explicitly exclude alternatives or mention when not to use it, despite having sibling security tools like electron_audit_security.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate complete custom protocol / deep linking setup for Electron. Produces protocol registration, URL handling in both single-instance and multi-instance modes, platform-specific configuration (macOS Info.plist, Windows registry, Linux .desktop), and electron-builder/forge config.
| Name | Required | Description | Default |
|---|---|---|---|
| routes | No | Routes to handle within the protocol | |
| protocol | Yes | Custom protocol scheme, e.g. 'myapp' (will handle myapp:// URLs) | |
| singleInstance | No | Enforce single instance -- new URLs focus the existing window (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'generate' implying a write/create operation, but annotations include readOnlyHint: true, which is a direct contradiction. This misleads the agent about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently lists key outputs. No extraneous text, though could be broken into bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration generation tool, the description covers protocol registration, URL handling, platform config, and builder config. No output schema needed as description explains what is produced. Annotations provide safety hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions (100% coverage). The tool description adds context about platform-specific configuration and single/multi-instance modes, enriching the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'generate complete custom protocol / deep linking setup for Electron' with specific outputs (protocol registration, URL handling, platform config, builder config). It distinguishes from siblings as the only deep linking configuration tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting up deep linking in Electron, and sibling tools are all different (audit, security, scaffold), making context clear. However, no explicit when-to-use or when-not-to-use is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate @electron/fuses configuration to harden your Electron app. Fuses are compile-time toggles that disable dangerous Electron features (like ELECTRON_RUN_AS_NODE, NODE_OPTIONS) and cannot be re-enabled by end users. Essential for production apps.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | 'recommended' for sensible defaults, 'strict' for maximum security, 'custom' to specify each fuse individually | |
| customFuses | No | Individual fuse settings (only for 'custom' level) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, and the description aligns by stating it generates configuration without side effects. It adds value by explaining that fuses are compile-time toggles that disable dangerous features, which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, every word adds value. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description doesn't detail the generated configuration format, but the purpose is clear. It covers the essential behavioral and usage context, making it adequate for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description provides examples of dangerous features (e.g., ELECTRON_RUN_AS_NODE) that add context but doesn't substantially clarify the levels beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates configuration to harden Electron apps using compile-time toggles (fuses) and lists specific disabled features (e.g., ELECTRON_RUN_AS_NODE, NODE_OPTIONS). This distinguishes it from sibling tools like electron_configure_csp or electron_audit_security.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as essential for production apps and notes that fuses cannot be re-enabled by users, implying critical security hardening. It lacks explicit when-not-to-use or alternatives, but the guidance is clear and contextually sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose Electron build/packaging errors from electron-builder, electron-forge, or electron-packager output. Identifies common failures: code signing errors, native module rebuild issues, ASAR packaging problems, missing platform-specific configuration, and __dirname path resolution bugs.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Target platform. Defaults to 'unknown' (auto-detect). | |
| buildTool | No | Which build tool produced the error. Defaults to 'unknown' (auto-detect). | |
| errorOutput | Yes | The build error output (stderr/stdout) to diagnose |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds no new behavioral traits, which is acceptable given the annotations are comprehensive. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and efficiently includes examples of diagnosed errors. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description does not mention the return format, which could be useful. However, given the annotations and clear purpose, it is mostly complete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description lists error types but does not add meaning beyond the schema for the parameters themselves. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it diagnoses Electron build/packaging errors and lists specific failure types (code signing, native module, ASAR, etc.), distinguishing it from sibling tools that focus on auditing, performance, or security.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly state when not to use it, the description implies it's for build error diagnosis, and sibling tools cover other areas (security, performance). A clear usage context is present, but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a clear, authoritative explanation of an Electron concept. Counters outdated tutorial content with accurate, version-aware information. Covers: process model, context isolation, sandbox, IPC, ASAR, fuses, code signing, and build tool comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| concept | Yes | The Electron concept to explain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about version-awareness and countering outdated content, but does not disclose any additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence defines purpose, second adds context and lists covered items. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple informational tool with one parameter and no output schema, the description adequately explains what the tool does and what concepts it covers. It could mention the output format (e.g., returns text), but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single enum parameter. The description lists the enum values, which adds no new semantics beyond the schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to provide authoritative explanations of Electron concepts. It lists specific covered concepts, distinguishing it from generic info tools, though there is a sibling tool for a specific concept (process model).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like electron_explain_process_model. The description does not specify when not to use or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a clear, version-aware explanation of Electron's multi-process architecture. Covers the main process, renderer processes, preload scripts, utility processes, contextBridge, and how they interact. Useful for understanding the mental model before building features.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Which aspect of the process model to explain | |
| electronVersion | No | Target Electron version for version-specific guidance (e.g. '28', '33', '41'). Defaults to latest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool is version-aware and covers specific topics, which are beyond the annotations' safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only explanation tool, the description covers the topics, version-awareness, and intended use case. No output schema exists, but the return format is implicit. Sufficient for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enums and descriptions for both parameters. The description restates the topic coverage but adds that electronVersion defaults to latest. No significant added meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'explain' and identifies the resource 'process model'. It distinguishes from sibling tools like electron_explain_concept and audit tools by focusing on multi-process architecture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is 'useful for understanding the mental model before building features', providing clear context. It does not exclude other uses or mention alternatives, but the sibling context implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete, secure preload.ts with contextBridge.exposeInMainWorld for multiple API methods. Produces the preload script, TypeScript declarations for window.electronAPI, and security best practices. Use this when you need to expose several main-process APIs to the renderer at once.
| Name | Required | Description | Default |
|---|---|---|---|
| methods | Yes | Array of methods to expose through the preload bridge | |
| namespace | No | The property name on window, e.g. 'electronAPI'. Defaults to 'electronAPI'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, establishing the tool as a safe, idempotent code generator. The description adds behavioral context by detailing the generated artifacts (preload script, declarations, security best practices) and focuses on generation rather than side effects. No contradictions or missing behavioral traits given the tool's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every word earns its place. It efficiently conveys purpose, outputs, and usage guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, one required), the description provides complete context: what it does, when to use it, what it produces, and security implications. Annotations cover safety, and no output schema is needed as the description already describes outputs. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having descriptive details (e.g., method name, channel, type, args, returnType). The description adds no new parameter semantics beyond the schema, only reiterating the context of multiple methods. Baseline score of 3 is appropriate as the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a complete, secure preload.ts with contextBridge.exposeInMainWorld for multiple API methods, and specifies outputs (preload script, TypeScript declarations, security best practices). It distinguishes from sibling tools by indicating it's for exposing several APIs at once, implying a difference from single-channel tools like electron_scaffold_ipc_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need to expose several main-process APIs to the renderer at once,' providing clear usage context. It implicitly suggests alternatives for single methods but does not explicitly name them or state when not to use it, which would enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate multi-window management boilerplate for Electron apps. Creates a WindowManager class that handles window lifecycle, inter-window communication, window state persistence, and proper cleanup. Supports common patterns like main + child windows, modal dialogs, and detached panels.
| Name | Required | Description | Default |
|---|---|---|---|
| windows | Yes | Windows to manage | |
| persistState | No | Whether to persist window positions/sizes across restarts (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool generates boilerplate (creating files), which contradicts the annotation 'readOnlyHint: true' that suggests no state modification. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, features, and patterns with no wasted words. Information is front-loaded and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the tool returns (e.g., files generated on disk or code output). It lacks details on side effects or output format, which is needed for a generator tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by explaining patterns (e.g., 'modal dialogs', 'detached panels') and features (inter-window communication, state persistence) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates multi-window management boilerplate for Electron apps, specifying the verb 'generate' and the resource 'WindowManager class'. It distinguishes from sibling tools (e.g., electron_generate_preload_bridge) by focusing solely on window management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions common patterns (main+child, modal dialogs, detached panels) and implies use in Electron app development. However, it does not explicitly list when not to use or contrast with siblings like electron_scaffold_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return metadata about the embedded Electron knowledge used by this MCP's analysis tools -- the date it was last verified against official Electron docs, the current Electron stable version at that time, and the supported version range for migration/deprecation checks. Call this when you need to know whether the advice from other tools is current.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the exact metadata returned (date, version, range), going beyond annotations. No additional behavioral traits are needed for this simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then usage. No waste, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully explains the tool's return value (three data points) and usage context. It is complete for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add parameter meaning. The baseline for zero parameters is 4, and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns metadata about embedded Electron knowledge, listing three specific data points (verified date, stable version, supported range). This distinguishes it from sibling tools that handle audits, migrations, or scaffolding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this when you need to know whether the advice from other tools is current,' providing clear use context. No alternative tools are mentioned, but the context is sufficient for a simple metadata retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Static analysis of Electron code for dangerous patterns: shell.openExternal with user input, @electron/remote usage, disabled webSecurity, missing navigation restrictions, unrestricted window creation, and other OWASP-style vulnerabilities specific to Electron.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code to analyze (main process, preload, or renderer) | |
| fileType | No | Which process this code runs in. Helps scope the analysis. Defaults to 'main'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context by specifying the analysis type and list of patterns checked, confirming no side effects and providing clear behavioral expectations for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently communicates the tool's purpose and key details. No filler, front-loaded with main function, and lists specific vulnerabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a linting tool with no output schema, the description covers the input parameters (via schema) and the specific issues checked. However, it does not hint at the output format (e.g., list of warnings), which could be added for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add extra meaning to parameters beyond what the schema already provides (code, fileType). No additional guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs static analysis of Electron code for dangerous patterns, listing specific vulnerabilities. It distinguishes itself from sibling audit/check tools by focusing on linting specific security issues like shell.openExternal, @electron/remote, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus similar sibling tools like electron_audit_security. The description implies it is for static analysis, but lacks context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a migration checklist for upgrading between Electron versions. Lists all breaking changes, deprecated APIs, and required code modifications between the current and target versions.
| Name | Required | Description | Default |
|---|---|---|---|
| targetVersion | Yes | Target Electron major version (e.g. 41) | |
| currentVersion | Yes | Current Electron major version (e.g. 28) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no additional behavioral context beyond what the annotations provide, such as authentication needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the main action. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately explains the output (checklist of breaking changes, deprecated APIs, code modifications). However, it does not specify the format or if it covers only major versions. Still, it is largely complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for both parameters, including types and valid ranges. The description only mentions 'current and target versions' without adding new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: generating a migration checklist for upgrading between Electron versions. It distinguishes itself from sibling tools like electron_knowledge_version, which provides version info, and others that audit or configure different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for version upgrades but does not explicitly state when to use this tool versus alternatives (e.g., checking deprecated APIs via electron_check_deprecated_apis). No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate complete IPC boilerplate for a new feature: ipcMain handler in the main process, preload bridge function with contextBridge, TypeScript type declarations, and renderer-side usage example. Produces all the files needed for a secure, type-safe IPC channel.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | TypeScript type for the arguments, e.g. '{ userId: string }' or 'string'. Omit for no arguments. | |
| direction | Yes | Communication direction for the channel | |
| returnType | No | TypeScript type for the return value (renderer-to-main only), e.g. '{ name: string; email: string }'. Omit for void. | |
| channelName | Yes | The IPC channel name, e.g. 'get-user-data', 'save-settings', 'open-file-dialog' | |
| description | Yes | What this IPC channel does, e.g. 'Fetches user profile from the database' | |
| apiNamespace | No | The namespace on window.electronAPI to group this under, e.g. 'users', 'settings'. Defaults to 'api'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool produces files, which is a write operation, but annotations specify readOnlyHint=true, creating a direct contradiction. No behavioral details beyond the output are provided, and the contradiction severely undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key action and outputs, and contains no unnecessary words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers generated files well, it omits the return value or success indication, and the annotation contradiction creates uncertainty about the tool's actual behavior. No output schema exists to fill this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described in the schema. The description adds no additional information about parameters, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates complete IPC boilerplate, specifying exactly what is produced: ipcMain handler, preload bridge, TypeScript types, and renderer example. This distinguishes it from siblings like electron_generate_preload_bridge which only generates the bridge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for new IPC channels but does not explicitly state when to use this tool over alternatives like electron_generate_preload_bridge. No exclusions or prerequisites are mentioned, relying on implicit understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete, secure, modern Electron project scaffold. Includes proper process separation, TypeScript configuration, framework integration, build tooling, security defaults, and an example IPC channel. Produces a full project structure ready to develop.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name (lowercase, hyphens ok), e.g. 'my-electron-app' | |
| features | No | Optional features to include | |
| buildTool | No | Build tool. Defaults to 'electron-vite'. | |
| framework | No | Frontend framework. Defaults to 'react'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true contradicts the description's implication that the tool creates files (a write operation). The description does not clarify behavioral traits beyond annotations, and the contradiction is a serious flaw.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with key attributes. However, it could be slightly more structured (e.g., listing features).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what the scaffold produces (e.g., directory structure). It vaguely says 'full project structure ready to develop' but lacks specifics on output location or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a clear description and enums where applicable. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a complete Electron project scaffold with specific attributes (process separation, TypeScript, framework, etc.). It distinguishes from sibling tools like electron_scaffold_ipc_channel, which focuses on a single IPC channel, and others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for starting a new Electron project but does not explicitly state when to use vs alternatives like electron_scaffold_ipc_channel or electron_generate_preload_bridge. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.15electron_configure_csp2 fields changedInput schema / properties / externalConnections / items / patternAdded value: +"^[^\\s;'\"]+$"Input schema / properties / externalImages / items / patternAdded value: +"^[^\\s;'\"]+$"electron_configure_deep_linking1 field changedInput schema / properties / protocol / patternAdded value: +"^[a-zA-Z][a-zA-Z0-9+.-]*(?::\\/\\/.*)?$"electron_generate_preload_bridge4 fields changedInput schema / properties / methods / items / properties / args / patternAdded value: +"^[^`\\r\\n]*$"Input schema / properties / methods / items / properties / name / patternAdded value: +"^[a-zA-Z_$][\\w$]*$"Input schema / properties / methods / items / properties / returnType / patternAdded value: +"^[^`\\r\\n]*$"Input schema / properties / namespace / patternAdded value: +"^[a-zA-Z_$][\\w$]*$"electron_scaffold_ipc_channel4 fields changedInput schema / properties / apiNamespace / patternAdded value: +"^[a-zA-Z_$][\\w$]*$"Input schema / properties / args / patternAdded value: +"^[^`\\r\\n]*$"Input schema / properties / channelName / patternAdded value: +"^[a-zA-Z0-9][a-zA-Z0-9._:-]*$"Input schema / properties / returnType / patternAdded value: +"^[^`\\r\\n]*$"electron_scaffold_project1 field changedInput schema / properties / name / patternAdded value: +"^[a-z0-9][a-z0-9._-]*$"v1.2.13electron_audit_ipc_securityelectron_audit_performanceelectron_audit_securityelectron_check_deprecated_apiselectron_configure_auto_updateelectron_configure_cspelectron_configure_deep_linkingelectron_configure_fuseselectron_diagnose_build_errorelectron_explain_conceptelectron_explain_process_modelelectron_generate_preload_bridgeelectron_generate_window_managerelectron_knowledge_versionelectron_lint_securityelectron_migrate_versionelectron_scaffold_ipc_channelelectron_scaffold_projectTools are generally distinct, but 'electron_audit_security' and 'electron_lint_security' have overlapping purposes (both check security patterns). Most other tools have clear boundaries.
All tools follow the pattern 'electron_verb_noun' (e.g., electron_audit_ipc_security, electron_configure_csp). Consistent and predictable.
18 tools cover a focused domain (Electron app development) without overwhelming. Each tool addresses a specific task, with good coverage of auditing, configuration, code generation, and explanation.
The set covers major areas: security/performance audits, configuration (CSP, auto-update, deep linking, fuses), scaffolding, IPC generation, migration, and diagnostics. Missing tools for packaging configuration beyond fuses, but scaffold_project likely includes basics.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
13 micro-tools for agents: read pages, verify email, convert, validate, diff, extract. AI-operated.
MCP-first toolbox for agents: KV storage, auth, queue, and utility tools. Free in early access.
130+ QA & dev tools for AI agents: prompt injection, RAG testing, VLM eval, guardrails. Free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/YawLabs/electron-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
