Skip to main content
Glama
0xpolarzero

luda

by 0xpolarzero
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

desktop_press_keys

Send deliberate keyboard chords like Ctrl+S or Return to a chosen window on Linux, validating state between repetitions for reliable shortcut execution.

Instructions

Send a deliberate chord, e.g. ctrl+s, ctrl+plus, ctrl+minus, Return, Tab, Escape or Down. Punctuation uses X11 names (plus, equal, bracketleft, slash); implicit Shift follows the current layout. count is 1–20 complete press/release repetitions, default 1. Revalidates target identity, focus and input state between repetitions; stops on the first failure and never retries. Automatically chooses independent input where supported or foreground control otherwise. Refuses held input on the selected devices and preserves their keyboard mapping. Foreground fallback can change human focus. Unavailable symbols return UNSUPPORTED_KEYMAP; text belongs in desktop_type. When a final companion receipt is available, progress reports fully dispatched, possibly partial and not-started repetitions. Dispatched count is not application completion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chordYes
countNo
window_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.4
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / count
      Added value: +{
+  "default": 1,
+  "title": "Count",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses revalidation between repetitions, stop-on-first-failure with no retry, automatic input-device selection, refusal of held input, preservation of keyboard mapping, possible human-focus changes, the UNSUPPORTED_KEYMAP error, and the distinction between dispatched and application-completed actions.

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?

The description is dense but every sentence adds distinct information, from examples and key naming rules to failure behavior and result semantics. It is front-loaded with the core purpose before moving into edge cases.

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?

Considering there is no output schema and no annotations, the description covers purpose, parameter constraints, failure modes, side effects, and even progress-report semantics. It is slightly opaque about the exact return/receipt structure and about what window_id should contain, but overall it is unusually complete.

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

Parameters3/5

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

The description adds strong semantics for chord (X11 key names, implicit Shift) and count (1-20 repetitions, default 1), which is essential because schema description coverage is 0%. However, the required window_id parameter is never explained, leaving a meaningful gap for a required argument.

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 opens with a specific verb and resource: 'Send a deliberate chord', followed by concrete examples like ctrl+s, Return, Tab and Down. It also distinguishes itself from keyboard text input by stating 'text belongs in desktop_type', so an agent can tell it apart from sibling tools.

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 clearly routes text input away from this tool with 'text belongs in desktop_type' and warns about focus-changing foreground fallback. It could be more explicit about when to prefer this over other siblings like desktop_paste or desktop_type_secret, but the chord-versus-text distinction is clear.

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