Skip to main content
Glama
Sign In
electron-stagewright

Electron Stagewright

by electron-stagewright
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Press a key or chord

electron_key

Press a key or chord in an Electron app, focusing a ref or selector when provided, to automate keyboard input and shortcuts.

Instructions

Press a key or chord (e.g. 'Enter', 'Control+A', 'ArrowDown'). Focuses ref/selector first when given; otherwise presses against the active element. For editors, click the visible content area first; reserve force:true for offscreen inputs that truly accept focus. Options: force, timeoutMs, waitForFocusMs, requireEditable. Returns: { ok, session_id, key, focused }. Errors: SELECTOR_NO_MATCH / REF_NOT_FOUND (carries similar_refs), ELEMENT_NOT_VISIBLE (retryable), NO_FOCUSED_EDITABLE, NOT_RUNNING, BAD_ARGUMENT (ref+selector both).

Input Schema

NameRequiredDescriptionDefault
keyYesKey or chord, e.g. 'Enter' or 'Control+A'.
refNoElement ref from a snapshot (resolves to [data-sw-ref="N"]). Provide ref OR selector.
forceNoBypass actionability checks (visibility/enabled/stable). Default false.
selectorNoCSS selector. Provide ref OR selector, not both.
sessionIdNoTarget session id. Omit when a single session is running.
timeoutMsNoActionability budget in ms (default 5000, clamped to 30000).
waitForFocusMsNoNo target: wait up to this many ms for an editable element to take focus.
requireEditableNoFail with NO_FOCUSED_EDITABLE unless keys go to an editable element.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.0
    • addedInput schema / properties / requireEditable
      Added value: +{
+  "description": "Fail with NO_FOCUSED_EDITABLE unless keys go to an editable element.",
+  "type": "boolean"
+}
    • addedInput schema / properties / waitForFocusMs
      Added value: +{
+  "description": "No target: wait up to this many ms for an editable element to take focus.",
+  "maximum": 10000,
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observedv0.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnly=false and openWorld=false, so the description carries the real burden and does: it discloses the return shape { ok, session_id, key, focused }, enumerates failure modes (SELECTOR_NO_MATCH/REF_NOT_FOUND with similar_refs, ELEMENT_NOT_VISIBLE retryable, NO_FOCUSED_EDITABLE, NOT_RUNNING, BAD_ARGUMENT), and explains focus/force behavior. It stops short of stating whether the key press is dispatched as down+up or how modifiers are handled.

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?

Front-loaded with the action and examples, then scoping rule, then editor caveat, then returns and errors. Dense but every clause carries usable information; the only filler is the short options enumeration.

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

Completeness5/5

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

For an 8-parameter, no-output-schema tool, the description supplies the missing pieces: return object keys, error taxonomy, and target-resolution rules. An agent can call it and interpret failures without further documentation.

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 coverage is 100%, so baseline is 3; the description earns above that by explaining the ref-vs-selector precedence ('Focuses ref/selector first when given') and the intent behind force:true rather than merely restating its definition. The 'Options:' list itself is redundant with the schema.

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?

Specific verb+resource with concrete key/chord examples ('Control+A', 'ArrowDown'). It does not explicitly name the sibling it displaces (electron_type, electron_type_into_editor, electron_press_sequence), so an agent must infer that boundary from the editor hint rather than from an explicit routing statement.

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?

Gives clear operating context: focuses ref/selector first when provided, otherwise targets the active element; for editors, click the visible content area first; reserve force:true for offscreen inputs that truly accept focus. Clear when-to-use guidance, but no explicit when-not or named alternative for multi-key sequences.

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