Skip to main content
Glama
YawLabs

@yawlabs/electron-mcp

Official
by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

electron_audit_security

Read-onlyIdempotent

Audit an Electron app against the official security checklist to detect vulnerabilities in BrowserWindow configuration, main process code, preload scripts, and HTML.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mainCodeNoMain process code -- used to detect non-HTTPS URLs in loadURL/loadFile calls
htmlContentNoContent of the main HTML file to check CSP meta tags
packageJsonNoContent of package.json to check Electron version and dependencies
preloadCodeNoContent of the preload script
electronVersionNoElectron major version if not in package.json (e.g. '41')
browserWindowConfigNoBrowserWindow constructor options as a JSON string or code snippet

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.13

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

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 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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools