Electron Stagewright guides

Public documentation for driving Electron apps over the Model Context Protocol. Start where your situation matches:

You are…	Read
New here and want a working session in minutes	Getting started
Verifying a published MCP host setup with a real Electron app	Try the packaged demo
Wiring the server into Claude Desktop, Cursor, or another client	Connect your MCP client
Loading, configuring, or diagnosing a plugin	Load, configure, and diagnose plugins
Deciding how to get a session against YOUR app	Launch, attach, or inject
Writing assertions an agent can act on	Assert UI state
Driving a code editor (Monaco, CodeMirror, EditContext)	Type into code editors
Debugging a flow — screenshots, console, dialogs, session traces	Capture diagnostics
Coming from electron-driver	Migrate from electron-driver
Deciding whether and how to expose the server	Security model
Trying to understand how it works, and why	Concepts
Comparing Electron MCP workflows before adopting one	Choose an Electron MCP server
Checking supported runtimes, platforms, and transports	Compatibility

The four kinds of docs here

These docs follow the Diátaxis split, so you can tell at a glance what a page is for:

Tutorial — learning-oriented. Getting started walks a first session end to end.
How-to — task-oriented. Connect your MCP client, Try the packaged demo, Launch, attach, or inject, Assert UI state, Type into code editors, Capture diagnostics, Load, configure, and diagnose plugins, and Migrate from electron-driver each solve one job.
Explanation — understanding-oriented. Concepts explains the agent-native model and why the server is shaped the way it is; the Security model explains the trust boundaries; Choose an Electron MCP server frames a capability-first evaluation against the surrounding ecosystem; Compatibility separates package ranges from combinations verified in CI.
Reference — information-oriented. TOOL-REFERENCE.md lists every tool (parameters, return shapes, error codes) generated from the live manifest, and the Architecture Decision Records record why each decision was made.

Conventions the guides assume

Every tool returns a JSON envelope discriminated by ok. On failure, branch on the stable code (never the prose), check retryable, and look at next_actions for the recommended recovery:

{
  "ok": false,
  "code": "SELECTOR_NO_MATCH",
  "error": "\"#missing\" matched no element.",
  "retryable": false,
  "next_actions": ["electron_snapshot()", "electron_find({ role, name_contains })"]
}

Sessions thread through every call: electron_launch / electron_attach / electron_inject return a session_id; pass it to subsequent calls (it may be omitted while exactly one session is live) and end the session with electron_stop.