kde-desktop-mcp

Overview Schema Source Related Servers Discussions Admin

kde_input_drag

Destructive

Drag between global logical-desktop pixel coordinates with bounded interpolation across listed displays and configurable steps, duration, and pauses to deliver real UI drag-and-drop gestures.

Instructions

Drag between global logical-desktop pixel coordinates. Every interpolated point must lie on a listed display; steps are limited to 1–64. Duration and start/end pauses are bounded to make real UI drag-and-drop gestures deliverable without changing their global-coordinate semantics. This can move the pointer or change the active window and is not bound to a particular window.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session": "<session>",
      "start_x": "<start_x>",
      "start_y": "<start_y>",
      "end_x": "<end_x>",
      "end_y": "<end_y>"
    },
    "name": "kde_input_drag"
  }
}

Input Schema

Name	Required	Description	Default
`end_x`	Yes
`end_y`	Yes
`steps`	No
`button`	No		left
`hold_ms`	No
`session`	Yes	Required target selector: a managed private session ID, or the exact value 'user-desktop' to explicitly opt into the real user desktop.
`start_x`	Yes
`start_y`	Yes
`duration_ms`	No
`end_pause_ms`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Beyond the annotations, the description discloses concrete operational constraints: every interpolated point must lie on a listed display, steps are capped at 1–64, and duration and start/end pauses are bounded. It also confirms the gesture is window-agnostic and may alter pointer position or active window, consistent with destructiveHint. It adds no information on error behavior when a point falls off-display or on permission requirements.

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?

Three sentences, front-loaded with the coordinate semantics and followed by constraints and side effects; no filler. The middle sentence is dense (limits, pauses, and coordinate fidelity packed together) but every clause carries operational meaning.

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

Completeness3/5

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

For a destructive, open-world input tool with 10 parameters, no output schema, and near-zero schema descriptions, the definition covers the riskiest aspects (off-display rejection, bounded timing, window-agnostic effects). It still omits the meaning of button/hold_ms and any indication of what a call returns or how failures are surfaced, so it is adequate rather than 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?

Schema description coverage is only 10% across 10 parameters, so the description must carry weight and it does explain the coordinate space (global logical desktop) and the step bounds. However, it says nothing about button, hold_ms, or the precisely bounded 'duration and pauses' values, so several parameters remain unexplained by either source.

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?

The first sentence gives a specific verb and resource ('Drag between global logical-desktop pixel coordinates'), which is clearly distinct from the click/key/type siblings. It stops short of naming an alternative tool or stating precisely when a drag should be preferred over click-and-hold sequences.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance relative to kde_input_click or kde_input_click_at. The closing sentence ('can move the pointer or change the active window and is not bound to a particular window') describes behavior rather than selection criteria, leaving the agent to infer context.

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