Skip to main content
Glama
kami-sqmf

Human Input MCP

by kami-sqmf

human_mouse_drag

Destructive

Drags with the left mouse button from the current cursor position to a client point and waits for completion without pre-positioning. Use it to automate drag gestures in Windows apps.

Instructions

Drag with the left button from the current observed cursor to a client point; waits for completion. Does not pre-position the cursor.

Input Schema

NameRequiredDescriptionDefault
xYes
yYes
hwndYes
jitter_pxNo
duration_msNo
overshoot_pxNo
pause_policyNo
threshold_pxNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already disclose destructive=true, idempotent=false, and readOnly=false. The description adds operationally important behavior: left-button drag, synchronous wait for completion, and no cursor pre-positioning. It still omits failure and permission details, but against the annotation baseline this is useful context.

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?

Two sentences, front-loaded with the operation and then a key constraint; neither sentence is filler. It is arguably terse for the schema complexity, but there is no structural waste.

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

Completeness2/5

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

For a destructive tool with 8 parameters, a nested pause_policy object, and no output schema, the description is too sparse. It does not explain hwnd targeting, optional drag controls, pause policy semantics, or failure behavior, leaving the agent under-informed beyond the core action.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only maps x/y as the client target and start point as the current cursor. It leaves hwnd, jitter_px, duration_ms, overshoot_px, threshold_px, and the nested pause_policy fields unexplained, which is a major gap for an 8-parameter tool.

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 names a specific operation—left-button drag—and defines both endpoints (current observed cursor to a client point), plus the completion behavior. It is distinguishable from human_mouse_move and human_mouse_click because it explicitly performs a drag and says it does not pre-position the cursor.

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

Usage Guidelines3/5

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

It implies the tool is for dragging from wherever the cursor currently is and warns that it will not move the cursor first, which is useful context. However, it does not state when to choose this over human_mouse_move plus human_mouse_click, nor what prerequisites such as an observed cursor must be met.

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