eda-agent

Overview Schema Source Related Servers Discussions Admin

app_send_keys

Send keyboard shortcuts or key sequences like Ctrl+S, Tab, or Escape to the focused element in EasyEDA Pro. Use it for canvas shortcuts, grid commits, and dialog responses that no control-based tool can reach.

Instructions

Send a key sequence to whatever currently has focus.

THE THINGS THAT TAKE NEITHER A CONTROL NOR A MENU: a canvas shortcut, a grid that commits on Enter, a dialog answered with Escape, a chord like Ctrl+Shift+D. Every other tool here addresses a control; this addresses the keyboard.

Space separated, each item a key or a '+' chord:

"escape"              one key
"ctrl+s"              a chord
"tab tab enter"       three in order

Modifiers: ctrl, alt, shift. Keys: enter, escape, tab, space, backspace, delete, the arrows, home, end, pageup, pagedown and F1 to F12. An unknown name is refused and the known ones listed, rather than sent as nothing.

THIS GOES WHEREVER FOCUS IS. Establish focus first, with app_click_menu or app_open_panel, and check the result afterwards: a keystroke has no read-back, so the reply says what was sent and never that it worked.

Input Schema

Name	Required	Description	Default
`sequence`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden, and it does: it warns the keystroke goes wherever focus is, states there is no read-back ('the reply says what was sent and never that it worked'), and documents the failure mode for unknown key names. These are exactly the behavioral traits an agent needs before invoking a focus-dependent input tool.

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?

Front-loaded with the action and the keyboard-vs-control distinction, then syntax, then the focus caveat — a sensible order. The all-caps framing line and poetic spacing are stylistic flourishes that cost some density, but no sentence is redundant.

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?

Single-parameter tool with an output schema available and no annotations; the description still covers invocation format, preconditions (focus), and postconditions (no verification of success). Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly: space-separated token syntax, '+' chord notation, three worked examples, an explicit modifier list, an explicit key list, and the refusal behavior for unknown names. This adds substantial meaning beyond the bare `sequence: string` schema.

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?

States a specific verb and resource: 'Send a key sequence to whatever currently has focus.' It also explicitly differentiates itself from siblings ('Every other tool here addresses a control; this addresses the keyboard'), so an agent can route between this and app_type_text or app_set_grid_cell without opening the schema.

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?

Gives concrete when-to-use cases (canvas shortcut, grid that commits on Enter, dialog answered with Escape, chords) and names prerequisites/alternatives: 'Establish focus first, with app_click_menu or app_open_panel, and check the result afterwards.' That is explicit routing guidance, not implied usage.

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

Deploy Server