Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The electron-mcp-server exhibits mixed quality across 44 tools. Strengths: Most tools have reasonable descriptions (4 static tools are well-documented); comprehensive tool coverage for Electron automation. Critical weaknesses: MAJORITY of dynamically-registered tools (40+ commands) have NO visible descriptions in the source code sample provided, only file references. The tools.ts excerpt shows staticTools array with descriptions, but the dynamicTools generation is truncated ('allComma' is incomplete). Without visibility into src/commands/*.ts files, parameter schemas, and descriptions for the 40 command-based tools, scoring must be conservative. Evidence-based assessment: 4 static tools (get_electron_window_info, list_electron_windows, electron_take_screenshot, read_electron_logs) have clear descriptions (90-150 chars, actionable); but these represent only 9% of the toolset. The remaining 40 tools are registered dynamically from allCommands, and descriptions are not visible in the provided source. Per HARD SCORING RULE: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' This applies to ~91% of tools here.
40 dynamically-registered tools (91% of toolset) have NO visible descriptions in source code provided. Per HARD SCORING RULE, tools not visible in actual source must be capped at 50. This is the primary quality limiter.
URGENT: Add full descriptions to all 40 command-based tools in src/commands/*/index.ts or wherever tool registration occurs. Each description must be 50-200 chars and answer: What does it do? When to call it? What does it return? Reference the 4 high-quality static tool descriptions as a model.
URGENT: Make visible the complete input schemas for all 40 tools. Ensure each parameter has: (a) type definition (string, number, boolean, enum); (b) description explaining the parameter's purpose and constraints; (c) required/optional marking; (d) enums for constrained values (e.g., storageType: 'localStorage' | 'sessionStorage'). Use zod-to-json-schema consistently as done for static tools.
Add confirmation/dry-run for electron_eval_command. Implement a pattern like: (1) electron_eval_command_preview(js_code) → returns the code to be executed without side effects; (2) user confirms; (3) electron_eval_command_execute(confirmation_token) → executes. Or require explicit confirmation_required: true parameter.
Add recovery guidance to electron_clear_storage. Document: (a) What scopes are cleared (localStorage, sessionStorage, cookies, all?); (b) Is this reversible? (c) Offer a pre-clear snapshot tool or suggest backing up with electron_local_storage_get_item before clearing.
Document selector-based tools with examples. For electron_click_by_selector, provide: 'CSS selector string (e.g., "button.submit", "#user-menu", "[aria-label=Save]"). If unsure of selector, call electron_find_elements to discover available elements and their selectors.' Reference CSS selector syntax constraints.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Take a screenshot of any running Electron application window. Returns base64 image data for AI analysis. No files created unless outputPath is specified. Pass `targetId` (from list_electron_windows) for unambiguous targeting when multiple Electron apps run on different debugging ports — `targetId` takes precedence over `windowTitle`.
Get information about running Electron applications and their windows. Automatically detects any Electron app with remote debugging enabled (port 9222).
List all available Electron window targets across all detected applications. Returns window IDs, titles, URLs, and ports. Use the returned IDs with any electron_* tool's targetId parameter to target specific windows.
read_electron_logsread onlysource verified55/100
Read console logs and output from running Electron applications. Useful for debugging and monitoring app behavior.
No input schemas visible for 40 command-based tools. Source excerpt truncates at 'allComma' without showing the command registration code. Per HARD SCORING RULE: 'If a tool has NO input schema at all: its schema score MUST be 0.' Cannot assess parameter types, required fields, enums, or validation constraints.
electron_eval_command tool (IRREVERSIBLE risk level) appears to allow arbitrary JavaScript execution in Electron context. No visible error handling, confirmation mechanism, or dry-run support. Violates confirmation-request pattern for irreversible operations.
electron_clear_storage tool (DESTRUCTIVE) has no visible description, schema, or recovery guidance. LLMs cannot determine the scope (localStorage only? sessionStorage too? both?) or consequences. No undo tool offered.
No visible error handling patterns. Tools that interact with DOM, wait for conditions, or perform I/O have no documented error cases, timeout behavior, or recovery guidance. LLMs cannot self-correct on failure.
No visible tool composition documentation. 40 query/interaction tools exist, but no guidance on which to call first (e.g., 'use electron_get_page_structure first to discover element selectors'). Forces LLMs to guess tool order.
targetId and windowTitle parameters appear across multiple tools but no visible documentation on precedence rules, resolution behavior (what if both provided? what if neither?), or how to discover valid IDs from list_electron_windows response.
Add error handling documentation to wait_* tools. Document timeouts, fallback behavior, and when to use alternative approaches. E.g., 'electron_wait_for_selector has a 5000ms default timeout. If element does not appear, returns timeout error with guidance: try electron_find_elements to verify element exists, or use electron_get_page_structure for debugging.'
Add tool-chain documentation in descriptions. E.g., read_electron_logs description should say: 'Often used after a failed action to diagnose why it failed. Combine with electron_debug_elements to trace element state.' This guides LLM sequencing.
Clarify targetId vs windowTitle parameter semantics in all tools that accept both. Document: 'targetId (integer from list_electron_windows) takes precedence if both provided. If neither provided, targets the active window. Invalid IDs return a helpful error: "Target ID 999 not found. Available IDs: 0, 1. Did you call list_electron_windows first?"'
Add rate-limiting and batching variants. Create electron_click_elements_batch(selectors: string[], delay_ms?: number) → clicks multiple selectors in sequence with optional delay. Reduces round-trips and tokens vs N sequential calls.
Document output schemas. For electron_find_elements, explicitly document the return structure: '[{ selector: string, text: string, attributes: Record<string, string>, visible: boolean, enabled: boolean }, ...]'. For list_electron_windows, return format with all available fields.
Add security documentation. Clarify that electron_eval_command can access Node.js APIs if Electron app has nodeIntegration:true, and warn about command injection via untrusted input. Document any secrets that should never appear in parameters.
Improve naming for ambiguous tools. 'electron_verify_form_state' is vague, does it check for required fields? Errors? Form validity? Rename to electron_check_form_validity or electron_get_form_errors for clarity.
Document return-value chains. If a tool returns element IDs, selectors, or targetIds, note that these can be passed to downstream tools. E.g., 'electron_find_elements returns selector strings that can be directly passed to electron_click_by_selector.'