electron-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| launch_appA | Spawn an Electron application via the |
| launch_via_npmA | Spawn an Electron application by running an npm script (typically |
| attach_appA | Register an already-running Electron instance as a debug session. The caller started the app with |
| stop_appA | Close every CDP client tied to the session and, if the MCP launched the app, kill the underlying process. A no-op for already-stopped sessions, so safe to call unconditionally in cleanup flows. |
| list_appsA | Return a snapshot of every tracked session (launched + attached), with pid, ports, status, uptime, and tracked window count. |
| ping_inspectorA | Open the Node inspector on the session's main process and evaluate |
| list_windowsA | Enumerate every CDP target exposed by the session's renderer debug port. |
| evaluateA | Run |
| navigateA | Call |
| screenshotA | Grab a PNG (or JPEG) of the target renderer via |
| get_main_logsA | Returns the spawned process's captured log lines (stdout + stderr interleaved in order of receipt). These typically include the app's main-process startup lines and any backend/proxy output it prints when running packaged. |
| get_console_messagesA | Returns |
| get_network_requestsA | Returns captured CDP Network events (request / response / finished / failed). For a page load, multiple entries will share the same |
| clear_logsA | Wipe session ring buffers — useful to set a zero point before driving an action. Omit |
| list_electron_api_methodsA | Return the names of every method exposed on |
| invoke_electron_apiA | Invoke any method exposed by the preload bridge. Returns the method's result (awaited if it's a promise). Use to test IPC handlers directly, e.g. |
| enable_ipc_loggingA | Inject a proxy over |
| get_ipc_logA | Drain any pending renderer-side IPC events into the session buffer and return the matching entries. Requires |
| get_app_pathsA | Returns |
| read_user_data_fileA | Safely read a file relative to the session's |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| sessions | JSON list of every session tracked by the MCP server. |
TDQS
Scored across 20 tools
Each tool targets a distinct aspect of Electron debugging (launching, attaching, logging, inspection, etc.), with clear boundaries even among similar logging tools. No two tools appear to overlap in purpose.
All tool names use lowercase snake_case with a consistent verb_noun pattern (e.g., list_windows, get_app_paths, launch_app). There is no mixing of conventions, making the set predictable.
20 tools is on the higher side, but each tool serves a specific need for a complex domain. Some tools like clear_logs and get_main_logs could arguably be combined, but the count is still reasonable.
The tools cover the full lifecycle of debugging an Electron app: launch/attach, inspect (renderer and main process), capture logs (console, IPC, network), navigate, screenshot, and stop. No obvious gaps for common tasks.