Skip to main content
Glama
agy_computer_use.mcp_server

agy_computer_use.mcp_server

by orakulzero

cu_scroll

Dispatch vertical mouse wheel scrolls at normalized coordinates on a 0–1000 grid, with optional dry-run and adjustable wheel delta for desktop automation.

Instructions

Dispatch vertical mouse wheel scroll at [0..1000] normalized coordinates.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cu_scroll"
  }
}

Input Schema

NameRequiredDescriptionDefault
norm_xNoX on [0..1000] grid.
norm_yNoY on [0..1000] grid.
dry_runNoSynthesize without OS dispatch.
scroll_deltaNoWheel delta (+/-120).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden and leaves out important traits: whether scrolling requires foreground focus, what happens with multiple/no wheel ticks, whether side effects occur on background windows, and what the default scroll behavior is. 'Dispatch' implies real OS input, but little else is disclosed.

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 a single front-loaded sentence with no filler or redundancy. Every word contributes to identifying the action and coordinate system.

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 an input-dispatch tool with no annotations, no output schema, and four parameters, the description is too thin. It omits focus requirements, default scroll amount/direction, and whether the tool waits or returns any status, which an agent needs to invoke it correctly.

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 coverage is 100%, so all four parameters are already documented, including norm_x, norm_y, dry_run, and scroll_delta. The description adds normalized coordinate context but does not explain scroll_delta direction/default or dry_run behavior beyond what the schema already provides.

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 description states a specific verb and resource: dispatching a vertical mouse-wheel scroll. It is clear what the tool does, but it does not distinguish it from sibling input tools such as cu_click or cu_bg_dispatch.

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 guidance on when to use this tool versus alternatives like cu_click or cu_bg_dispatch, nor any prerequisites such as requiring a focused window. Usage is only implied by the verb 'scroll'.

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