Skip to main content
Glama
halilural

Electron MCP Server

by halilural
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Electron MCP Server

CI Publish to npm npm version npm downloads node GitHub license MCP

Control any Electron app with natural language. An MCP server that lets AI assistants (Claude, Cursor, VS Code, โ€ฆ) drive your Electron app: click buttons, fill forms, take screenshots, read console logs, and run JavaScript inside it โ€” all over the Chrome DevTools Protocol, with no changes to your app.

npx -y electron-mcp-server

Then ask your AI: "Click the Settings button in my Electron app and screenshot the result."

Why you might want it

  • ๐Ÿค– AI-driven UI automation โ€” describe the interaction ("click Submit", "fill the email field"); no selector wrangling

  • ๐Ÿ› Debugging without DevTools โ€” console logs and page structure pulled straight into the chat

  • ๐Ÿ“ธ Screenshots on demand โ€” returned as image data the AI can actually look at

  • โšก Zero app changes โ€” attaches over CDP to any Electron app started with --remote-debugging-port=9222

  • ๐Ÿ”’ Security levels โ€” strict โ†’ development, so you choose how much the AI may do

  • ๐Ÿงช Automated E2E flows โ€” turn manual test steps into repeatable AI-run scenarios

The 4 tools it exposes: get_electron_window_info, take_screenshot, send_command_to_electron (UI interaction + eval), read_electron_logs.

Demo

See the Electron MCP Server in action:

Watch Demo Video

๐ŸŽฌ Watch Full Demo on Vimeo

Watch how easy it is to automate Electron applications with AI-powered MCP commands.

Related MCP server: MCP Selenium Server

๐Ÿ”’ Security & Configuration

Configurable security levels to balance safety with functionality:

Security Levels

  • ๐Ÿ”’ STRICT: Maximum security for production environments

  • โš–๏ธ BALANCED: Default security with safe UI interactions (recommended)

  • ๐Ÿ”“ PERMISSIVE: More functionality for trusted environments

  • ๐Ÿ› ๏ธ DEVELOPMENT: Minimal restrictions for development/testing

Environment Configuration

Configure the security level and other settings through your MCP client configuration:

VS Code MCP Settings:

{
  "mcp": {
    "servers": {
      "electron": {
        "command": "npx",
        "args": ["-y", "electron-mcp-server"],
        "env": {
          "SECURITY_LEVEL": "balanced",
          "SCREENSHOT_ENCRYPTION_KEY":"your-32-byte-hex-string"
        }
      }
    }
  }
}

Claude Desktop Configuration:

{
  "mcpServers": {
    "electron": {
      "command": "npx",
      "args": ["-y", "electron-mcp-server"],
      "env": {
        "SECURITY_LEVEL": "balanced",
        "SCREENSHOT_ENCRYPTION_KEY":"your-32-byte-hex-string"
      }
    }
  }
}

Alternative: Local .env file (for development):

# Create .env file in your project directory
SECURITY_LEVEL=balanced
SCREENSHOT_ENCRYPTION_KEY=your-32-byte-hex-string

Security Level Behaviors:

Level

UI Interactions

DOM Queries

Property Access

Assignments

Function Calls

Risk Threshold

strict

โŒ Blocked

โŒ Blocked

โœ… Allowed

โŒ Blocked

โŒ None allowed

Low

balanced

โœ… Allowed

โœ… Allowed

โœ… Allowed

โŒ Blocked

โœ… Safe UI functions

Medium

permissive

โœ… Allowed

โœ… Allowed

โœ… Allowed

โœ… Allowed

โœ… Extended UI functions

High

development

โœ… Allowed

โœ… Allowed

โœ… Allowed

โœ… Allowed

โœ… All functions

Critical

Environment Setup:

  1. Copy .env.example to .env

  2. Set SECURITY_LEVEL to your desired level

  3. Configure other security settings as needed

cp .env.example .env
# Edit .env and set SECURITY_LEVEL=balanced

Secure UI Interaction Commands

Instead of raw JavaScript eval, use these secure commands:

// โœ… Secure button clicking
{
  "command": "click_by_text",
  "args": { "text": "Create New Encyclopedia" }
}

// โœ… Secure element selection
{
  "command": "click_by_selector",
  "args": { "selector": "button[title='Create']" }
}

// โœ… Secure keyboard shortcuts
{
  "command": "send_keyboard_shortcut",
  "args": { "text": "Ctrl+N" }
}

// โœ… Secure navigation
{
  "command": "navigate_to_hash",
  "args": { "text": "create" }
}

See SECURITY_CONFIG.md for detailed security documentation.

๐ŸŽฏ Proper MCP Usage Guide

โš ๏ธ Critical: Argument Structure

The most common mistake when using this MCP server is incorrect argument structure for the send_command_to_electron tool.

โŒ Wrong (causes "selector is empty" errors):

{
  "command": "click_by_selector",
  "args": "button.submit-btn"  // โŒ Raw string - WRONG!
}

โœ… Correct:

{
  "command": "click_by_selector",
  "args": {
    "selector": "button.submit-btn"  // โœ… Object with selector property
  }
}

๐Ÿ“‹ Command Argument Reference

Command

Required Args

Example

click_by_selector

{"selector": "css-selector"}

{"selector": "button.primary"}

click_by_text

{"text": "button text"}

{"text": "Submit"}

fill_input

{"value": "text", "selector": "..."} or {"value": "text", "placeholder": "..."}

{"placeholder": "Enter name", "value": "John"}

send_keyboard_shortcut

{"text": "key combination"}

{"text": "Ctrl+N"}

eval

{"code": "javascript"}

{"code": "document.title"}

get_title, get_url, get_body_text

No args needed

{} or omit args

๐Ÿ”„ Recommended Workflow

  1. Inspect: Start with get_page_structure or debug_elements

  2. Target: Use specific selectors or text-based targeting

  3. Interact: Use the appropriate command with correct argument structure

  4. Verify: Take screenshots or check page state

// Step 1: Understand the page
{
  "command": "get_page_structure"
}

// Step 2: Click button using text (most reliable)
{
  "command": "click_by_text",
  "args": {
    "text": "Create New Encyclopedia"
  }
}

// Step 3: Fill form field
{
  "command": "fill_input",
  "args": {
    "placeholder": "Enter encyclopedia name",
    "value": "AI and Machine Learning"
  }
}

// Step 4: Submit with selector
{
  "command": "click_by_selector",
  "args": {
    "selector": "button[type='submit']"
  }
}

๐Ÿ› Troubleshooting Common Issues

Error

Cause

Solution

"The provided selector is empty"

Passing string instead of object

Use {"selector": "..."}

"Element not found"

Wrong selector

Use get_page_structure first

"Command blocked"

Security restriction

Check security level settings

"Click prevented - too soon"

Rapid consecutive clicks

Wait before retrying

๐Ÿ› ๏ธ Security Features

Enterprise-grade security built for safe AI-powered automation:

  • ๐Ÿ”’ Sandboxed Execution: All code runs in isolated environments with strict resource limits

  • ๐Ÿ” Input Validation: Advanced static analysis detects and blocks dangerous code patterns

  • ๐Ÿ“ Comprehensive Auditing: Encrypted logs track all operations with full traceability

  • ๐Ÿ–ผ๏ธ Secure Screenshots: Encrypted screenshot data with clear user notifications

  • โš ๏ธ Risk Assessment: Automatic threat detection with configurable security thresholds

  • ๐Ÿšซ Zero Trust: Dangerous functions like eval, file system access, and network requests are blocked by default

Safety First: Every command is analyzed, validated, and executed in a secure sandbox before reaching your application.

๏ฟฝ๐Ÿš€ Key Features

๐ŸŽฎ Application Control & Automation

  • Launch & Manage: Start, stop, and monitor Electron applications with full lifecycle control

  • Interactive Automation: Execute JavaScript code directly in running applications via WebSocket

  • UI Testing: Automate button clicks, form interactions, and user workflows

  • Process Management: Track PIDs, monitor resource usage, and handle graceful shutdowns

๐Ÿ“Š Advanced Observability

  • Screenshot Capture: Non-intrusive visual snapshots using Playwright and Chrome DevTools Protocol

  • Real-time Logs: Stream application logs (main process, renderer, console) with filtering

  • Window Information: Get detailed window metadata, titles, URLs, and target information

  • System Monitoring: Track memory usage, uptime, and performance metrics

๐Ÿ› ๏ธ Development Productivity

  • Universal Compatibility: Works with any Electron app without requiring code modifications

  • DevTools Integration: Leverage Chrome DevTools Protocol for powerful debugging capabilities

  • Build Automation: Cross-platform building for Windows, macOS, and Linux

  • Environment Management: Clean environment handling and debugging port configuration

๐Ÿ“ฆ Installation

VS Code Integration (Recommended)

Install with NPX in VS Code

Add to your VS Code MCP settings:

{
  "mcp": {
    "servers": {
      "electron": {
        "command": "npx",
        "args": ["-y", "electron-mcp-server"],
        "env": {
          "SECURITY_LEVEL": "balanced",
          "SCREENSHOT_ENCRYPTION_KEY": "your-32-byte-hex-string-here"
        }
      }
    }
  }
}

Claude Desktop Integration

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "electron": {
      "command": "npx",
      "args": ["-y", "electron-mcp-server"],
      "env": {
        "SECURITY_LEVEL": "balanced",
        "SCREENSHOT_ENCRYPTION_KEY": "your-32-byte-hex-string-here"
      }
    }
  }
}

Global Installation

npm install -g electron-mcp-server

๐Ÿ”ง Available Tools

launch_electron_app

Launch an Electron application with debugging capabilities.

{
  "appPath": "/path/to/electron-app",
  "devMode": true,  // Enables Chrome DevTools Protocol on port 9222
  "args": ["--enable-logging", "--dev"]
}

Returns: Process ID and launch confirmation

get_electron_window_info

Get comprehensive window and target information via Chrome DevTools Protocol.

{
  "includeChildren": true  // Include child windows and DevTools instances
}

Returns:

  • Window IDs, titles, URLs, and types

  • DevTools Protocol target information

  • Platform details and process information

take_screenshot

Capture high-quality screenshots using Playwright and Chrome DevTools Protocol.

{
  "outputPath": "/path/to/screenshot.png",  // Optional: defaults to temp directory
  "windowTitle": "My App"  // Optional: target specific window
}

Features:

  • Non-intrusive capture (doesn't bring window to front)

  • Works with any Electron app

  • Fallback to platform-specific tools if needed

send_command_to_electron

Execute JavaScript commands in the running Electron application via WebSocket.

{
  "command": "eval",  // Built-in commands: eval, get_title, get_url, click_button, console_log
  "args": {
    "code": "document.querySelector('button').click(); 'Button clicked!'"
  }
}

Enhanced UI Interaction Commands:

  • find_elements: Analyze all interactive UI elements with their properties and positions

  • click_by_text: Click elements by their visible text, aria-label, or title (more reliable than selectors)

  • fill_input: Fill input fields by selector, placeholder text, or associated label text

  • select_option: Select dropdown options by value or visible text

  • get_page_structure: Get organized overview of all page elements (buttons, inputs, selects, links)

  • get_title: Get document title

  • get_url: Get current URL

  • get_body_text: Extract visible text content

  • click_button: Click buttons by CSS selector (basic method)

  • console_log: Send console messages

  • eval: Execute custom JavaScript code

Recommended workflow: Use get_page_structure first to understand available elements, then use specific interaction commands like click_by_text or fill_input.

read_electron_logs

Stream application logs from main process, renderer, and console.

{
  "logType": "all",  // Options: "all", "main", "renderer", "console"
  "lines": 50,       // Number of recent lines
  "follow": false    // Stream live logs
}

close_electron_app

Gracefully close the Electron application.

{
  "force": false  // Force kill if unresponsive
}

build_electron_app

Build Electron applications for distribution.

{
  "projectPath": "/path/to/project",
  "platform": "darwin",  // win32, darwin, linux
  "arch": "x64",         // x64, arm64, ia32
  "debug": false
}

๐Ÿ’ก Usage Examples

Smart UI Interaction Workflow

// 1. First, understand the page structure
await send_command_to_electron({
  command: 'get_page_structure',
});

// 2. Click a button by its text (much more reliable than selectors)
await send_command_to_electron({
  command: 'click_by_text',
  args: {
    text: 'Login', // Finds buttons containing "Login" in text, aria-label, or title
  },
});

// 3. Fill inputs by their label or placeholder text
await send_command_to_electron({
  command: 'fill_input',
  args: {
    text: 'username', // Finds input with label "Username" or placeholder "Enter username"
    value: 'john.doe@example.com',
  },
});

await send_command_to_electron({
  command: 'fill_input',
  args: {
    text: 'password',
    value: 'secretpassword',
  },
});

// 4. Select dropdown options by visible text
await send_command_to_electron({
  command: 'select_option',
  args: {
    text: 'country', // Finds select with label containing "country"
    value: 'United States', // Selects option with this text
  },
});

// 5. Take a screenshot to verify the result
await take_screenshot();

Advanced Element Detection

// Find all interactive elements with detailed information
await send_command_to_electron({
  command: 'find_elements',
});

// This returns detailed info about every clickable element and input:
// {
//   "type": "clickable",
//   "text": "Submit Form",
//   "id": "submit-btn",
//   "className": "btn btn-primary",
//   "ariaLabel": "Submit the registration form",
//   "position": { "x": 100, "y": 200, "width": 120, "height": 40 },
//   "visible": true
// }

Automated UI Testing

// Launch app in development mode
await launch_electron_app({
  appPath: '/path/to/app',
  devMode: true,
});

// Take a screenshot
await take_screenshot();

// Click a button programmatically
await send_command_to_electron({
  command: 'eval',
  args: {
    code: "document.querySelector('#submit-btn').click()",
  },
});

// Verify the result
await send_command_to_electron({
  command: 'get_title',
});

Development Debugging

// Get window information
const windowInfo = await get_electron_window_info();

// Extract application data
await send_command_to_electron({
  command: 'eval',
  args: {
    code: 'JSON.stringify(window.appState, null, 2)',
  },
});

// Monitor logs
await read_electron_logs({
  logType: 'all',
  lines: 100,
});

Performance Monitoring

// Get system information
await send_command_to_electron({
  command: 'eval',
  args: {
    code: '({memory: performance.memory, timing: performance.timing})',
  },
});

// Take periodic screenshots for visual regression testing
await take_screenshot({
  outputPath: '/tests/screenshots/current.png',
});

๐Ÿ—๏ธ Architecture

Chrome DevTools Protocol Integration

  • Universal Compatibility: Works with any Electron app that has remote debugging enabled

  • Real-time Communication: WebSocket-based command execution with the renderer process

  • No App Modifications: Zero changes required to target applications

Process Management

  • Clean Environment: Handles ELECTRON_RUN_AS_NODE and other environment variables

  • Resource Tracking: Monitors PIDs, memory usage, and application lifecycle

  • Graceful Shutdown: Proper cleanup and process termination

Cross-Platform Support

  • macOS: Uses Playwright CDP with screencapture fallback

  • Windows: PowerShell-based window detection and capture

  • Linux: X11 window management (planned)

๐Ÿงช Development

Prerequisites

  • Node.js 20+

  • TypeScript 4.5+

  • Electron - Required for running and testing Electron applications

    # Install Electron globally (recommended)
npm install -g electron

# Or install locally in your project
npm install electron --save-dev

Target Application Setup

For the MCP server to work with your Electron application, you need to enable remote debugging. Add this code to your Electron app's main process:

const { app } = require('electron');
const isDev = process.env.NODE_ENV === 'development' || process.argv.includes('--dev');

// Enable remote debugging in development mode
if (isDev) {
  app.commandLine.appendSwitch('remote-debugging-port', '9222');
}

Alternative approaches:

# Launch your app with debugging enabled
electron . --remote-debugging-port=9222

# Or via npm script
npm run dev -- --remote-debugging-port=9222

Note: The MCP server automatically scans ports 9222-9225 to detect running Electron applications with remote debugging enabled.

Setup

git clone https://github.com/halilural/electron-mcp-server.git
cd electron-mcp-server

npm install
npm run build

# Run tests
npm test

# Development mode with auto-rebuild
npm run dev

Testing

The project includes comprehensive test files for React compatibility:

# Run React compatibility tests
cd tests/integration/react-compatibility
electron test-react-electron.js

See tests/integration/react-compatibility/README.md for detailed testing instructions and scenarios.

React Compatibility

This MCP server has been thoroughly tested with React applications and handles common React patterns correctly:

  • โœ… React Event Handling: Properly handles preventDefault() in click handlers

  • โœ… Form Input Detection: Advanced scoring algorithm works with React-rendered inputs

  • โœ… Component Interaction: Compatible with React components, hooks, and state management

Project Structure

src/
โ”œโ”€โ”€ handlers.ts      # MCP tool handlers
โ”œโ”€โ”€ index.ts         # Server entry point
โ”œโ”€โ”€ tools.ts         # Tool definitions
โ”œโ”€โ”€ screenshot.ts    # Screenshot functionality
โ”œโ”€โ”€ utils/
โ”‚   โ”œโ”€โ”€ process.ts   # Process management & DevTools Protocol
โ”‚   โ”œโ”€โ”€ logs.ts      # Log management
โ”‚   โ””โ”€โ”€ project.ts   # Project scaffolding
โ””โ”€โ”€ schemas/         # JSON schemas for validation

๐Ÿ” Security & Best Practices

  • Sandboxed Execution: All JavaScript execution is contained within the target Electron app

  • Path Validation: Only operates on explicitly provided application paths

  • Process Isolation: Each launched app runs in its own process space

  • No Persistent Access: No permanent modifications to target applications

๐Ÿค Contributing

We welcome contributions! Please see our Contributing Guide for details.

Before reporting issues: Please use the standardized ISSUE_TEMPLATE.md for proper bug reporting format. For React compatibility problems or similar technical issues, also review REACT_COMPATIBILITY_ISSUES.md for detailed debugging examples, including proper command examples, error outputs, and reproduction steps.

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/awesome-feature)

  3. Commit your changes (git commit -m 'Add awesome feature')

  4. Push to the branch (git push origin feature/awesome-feature)

  5. Open a Pull Request

๐Ÿ“„ License

MIT License - see LICENSE file for details.

โ˜• Support

If this project helped you, consider buying me a coffee! โ˜•

Ko-fi

Your support helps me maintain and improve this project. Thank you! ๐Ÿ™

๐Ÿ™ Acknowledgments

๐Ÿ”— Links

Ready to supercharge your Electron development with AI-powered automation? Install the MCP server and start building smarter workflows today! ๐Ÿš€

Available Tools

4 tools
get_electron_window_infoB

Get information about running Electron applications and their windows. Automatically detects any Electron app with remote debugging enabled (port 9222).

ParametersJSON Schema
NameRequiredDescriptionDefault
includeChildrenNoInclude child windows information

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool automatically detects apps with remote debugging on port 9222, which is useful behavioral context. However, it lacks details on permissions needed, rate limits, error handling, or what specific information is returned (e.g., window titles, IDs, states). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds crucial context about automatic detection. Both sentences earn their place by providing essential information without redundancy or fluff, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (detecting apps and retrieving window info), no annotations, no output schema, and 1 parameter with full schema coverage, the description is moderately complete. It covers the what and how (automatic detection on port 9222) but lacks details on return values, error cases, or integration with sibling tools. It's adequate as a starting point but has clear gaps for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter with 100% description coverage, so the schema already documents 'includeChildren' as a boolean to include child windows. The description does not add any parameter-specific details beyond what the schema provides, such as examples or implications of setting it true/false. With high schema coverage, the baseline is 3, and the description does not compensate with extra semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get information about running Electron applications and their windows.' It specifies the verb ('Get information') and resource ('running Electron applications and their windows'), and distinguishes from sibling tools like read_electron_logs or send_command_to_electron by focusing on window info rather than logs or commands. However, it doesn't explicitly differentiate from take_screenshot, which might also involve window info, keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating it 'Automatically detects any Electron app with remote debugging enabled (port 9222),' which suggests when to use it (when such apps are running). However, it lacks explicit guidance on when to use this tool vs. alternatives like read_electron_logs for logs or take_screenshot for visual data, and does not mention any exclusions or prerequisites beyond the debugging requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_electron_logsB

Read console logs and output from running Electron applications. Useful for debugging and monitoring app behavior.

ParametersJSON Schema
NameRequiredDescriptionDefault
followNoWhether to follow/tail the logs
linesNoNumber of recent lines to read (default: 100)
logTypeNoType of logs to read

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is for 'debugging and monitoring,' which suggests read-only behavior, but doesn't explicitly state whether it's safe, requires permissions, has rate limits, or details the output format. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, consisting of two sentences that directly address purpose and usage without any wasted words. It is front-loaded with the core function and efficiently adds context, making it easy to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and hints at usage but lacks details on behavioral aspects like safety, permissions, or output format. Without annotations or an output schema, more context would be beneficial, but it meets a basic threshold for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear documentation for all parameters ('follow', 'lines', 'logType'), including an enum for 'logType'. The description adds no additional parameter information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 when no param info is added in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Read console logs and output from running Electron applications.' It specifies the verb ('Read') and resource ('console logs and output from running Electron applications'), making the function evident. However, it doesn't explicitly distinguish this tool from its siblings (e.g., 'get_electron_window_info' or 'send_command_to_electron'), which would be needed for a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some usage context by stating it's 'Useful for debugging and monitoring app behavior,' which implies when to use it. However, it doesn't offer explicit guidance on when to choose this tool over alternatives (e.g., vs. 'get_electron_window_info' for window info or 'send_command_to_electron' for commands), nor does it mention any exclusions or prerequisites, keeping it at an implied level.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_command_to_electronA

Send JavaScript commands to any running Electron application via Chrome DevTools Protocol.

Enhanced UI interaction commands:

  • 'find_elements': Analyze all interactive elements (buttons, inputs, selects) with their properties

  • 'click_by_text': Click elements by their visible text, aria-label, or title

  • 'click_by_selector': Securely click elements by CSS selector

  • 'fill_input': Fill input fields by selector, placeholder text, or associated label

  • 'select_option': Select dropdown options by value or text

  • 'send_keyboard_shortcut': Send keyboard shortcuts like 'Ctrl+N', 'Meta+N', 'Enter', 'Escape'

  • 'navigate_to_hash': Safely navigate to hash routes (e.g., '#create', '#settings')

  • 'get_page_structure': Get organized overview of page elements (buttons, inputs, selects, links)

  • 'debug_elements': Get debugging info about buttons and form elements on the page

  • 'verify_form_state': Check current form state and validation status

  • 'get_title', 'get_url', 'get_body_text': Basic page information

  • 'eval': Execute custom JavaScript code with enhanced error reporting

IMPORTANT: Arguments must be passed as an object with the correct properties:

Examples:

  • click_by_selector: {"selector": "button.submit-btn"}

  • click_by_text: {"text": "Submit"}

  • fill_input: {"placeholder": "Enter name", "value": "John Doe"}

  • fill_input: {"selector": "#email", "value": "user@example.com"}

  • send_keyboard_shortcut: {"text": "Enter"}

  • eval: {"code": "document.title"}

Use 'get_page_structure' or 'debug_elements' first to understand available elements, then use specific interaction commands.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoArguments for the command - must be an object with appropriate properties based on the command type
commandYesCommand to send to the Electron process

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing behavioral traits: it explains the enhanced UI interaction capabilities, emphasizes secure clicking ('Securely click'), safe navigation ('Safely navigate'), and enhanced error reporting for eval. However, it doesn't mention authentication needs, rate limits, or what happens on command failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose statement, command listing, argument format explanation, examples, and usage guidance. While comprehensive, some redundancy exists (e.g., listing all commands could be more concise). Every sentence adds value, but it's slightly longer than optimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple command types, nested parameters) and no output schema, the description does well by explaining command behaviors, argument structures, and usage patterns. However, it doesn't describe return values or error responses, which would be helpful since there's no output schema. The coverage is strong but not fully complete for such a multifaceted tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 significant value by explaining the command types and their required argument structures with concrete examples. It clarifies that 'Arguments must be passed as an object with the correct properties' and provides specific mappings between commands and their parameter needs (e.g., click_by_selector requires selector, fill_input requires value).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Send JavaScript commands to any running Electron application via Chrome DevTools Protocol' - a specific verb ('Send') with clear resource ('JavaScript commands to Electron application'). It distinguishes from siblings like get_electron_window_info (info gathering), read_electron_logs (log reading), and take_screenshot (screenshot capture) by focusing on interactive command execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use specific commands: 'Use get_page_structure or debug_elements first to understand available elements, then use specific interaction commands.' It also distinguishes between different command types (e.g., click_by_text vs click_by_selector) and provides clear examples for when to use each approach.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

take_screenshotA

Take a screenshot of any running Electron application window. Returns base64 image data for AI analysis. No files created unless outputPath is specified.

ParametersJSON Schema
NameRequiredDescriptionDefault
outputPathNoPath to save the screenshot (optional, defaults to temp directory)
windowTitleNoSpecific window title to screenshot (optional)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: that it returns base64 image data, creates no files by default, and only creates files when outputPath is specified. However, it doesn't mention potential limitations like what happens if no Electron windows are running, performance characteristics, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with three sentences that each earn their place: states the action and target, specifies the return format and purpose, and clarifies the file creation behavior. No wasted words, front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a screenshot tool with 2 parameters, 100% schema coverage, and no output schema, the description provides good context about what the tool does and its behavior. However, without annotations or output schema, it could benefit from more detail about the return format structure or error handling, though the base64 return is mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters well. The description adds minimal value beyond the schema - it mentions that outputPath is optional and defaults to temp directory (already in schema) and implies windowTitle is optional (already in schema). Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Take a screenshot') and resource ('any running Electron application window'), distinguishing it from sibling tools like get_electron_window_info (which provides info) or send_command_to_electron (which sends commands). It explicitly mentions what the tool does and what it returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool (for capturing screenshots of Electron apps for AI analysis) and mentions the optional outputPath parameter for file creation. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation2/5

The tool set has significant overlap and unclear boundaries. The first three tools (get_electron_window_info, read_electron_logs, send_command_to_electron) are distinct, but the 'Enhanced UI interaction commands' section contains 14 tools that are poorly differentiated. For example, 'debug_elements' and 'get_page_structure' seem to serve similar purposes, and 'click_by_text' vs 'click_by_selector' are just different targeting methods rather than distinct operations. This creates confusion about which tool to use for basic UI tasks.

Naming Consistency2/5

The naming conventions are inconsistent and chaotic. The first three tools use snake_case with clear verb_noun patterns, but the UI interaction tools mix styles: some use snake_case ('click_by_text'), others use camelCase ('getPageStructure' in the description but 'get_page_structure' as the tool name), and some are just verbs ('eval'). There's no discernible pattern across the entire set, making it difficult to predict tool names.

Tool Count3/5

With 17 total tools (3 core + 14 UI interaction), the count is borderline heavy for an Electron automation server. While Electron automation can justify many tools, the UI interaction section feels bloated with redundant or overly specific tools (e.g., separate tools for 'get_title', 'get_url', and 'get_body_text' instead of a unified 'get_page_info'). The count would be more appropriate if the UI tools were consolidated into fewer, more general-purpose tools.

Completeness4/5

For an Electron automation server, the tool surface is reasonably complete. It covers core areas: window detection, log reading, command execution, UI interaction (with extensive element targeting methods), and screenshots. The main gap is the lack of window management tools (resize, minimize, close windows) and application lifecycle control (launch/quit apps). However, the existing tools cover most common automation workflows, with the UI interaction section being particularly thorough despite its redundancy issues.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Selenium Server

    sapangupta63
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server implementation that enables browser automation through standardized MCP clients, supporting features like navigation, element interaction, and screenshots across Chrome, Firefox, and Edge browsers.
    907
    MIT

  • electron-mcp

    iamvinitk
    A
    license
    A
    quality
    D
    maintenance
    MCP server for interacting with and debugging Electron apps, providing tools for window automation, IPC, logs, and main-process state via CDP and Node inspector.
    20
    15
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/halilural/electron-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server