Skip to main content
Glama
Sign In
OpenCU

OpenCU

by Daily-AC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

scroll

Move an app view up, down, left, or right by element index or screenshot coordinates; returns updated text or a fresh screenshot for verification.

Instructions

Scroll an observed element or fresh screenshot coordinate. Returns current state: text for indexed input, plus a new screenshot for coordinate input.

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": {
      "app": "<app>",
      "direction": "<direction>"
    },
    "name": "scroll"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoX pixel coordinate in the most recently returned app-window screenshot; requires a screenshot after the last UI action.
yNoY pixel coordinate in that same app-window screenshot.
appYesApp name or full app path; macOS bundle ID; macOS and Windows pid:<pid>; Windows process name, window title fragment, or Start-menu shortcut name; Linux desktop entry name, executable name or window title fragment
pagesNo
scopeNomacOS and Windows: element index from the latest returned state. Read only its retained subtree, renumbered from [1], including after actions. If it disappears, return the whole window with a notice. Linux returns INVALID_ARGUMENT.
directionYes
element_indexNoElement index from the latest returned app state

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent already knows this mutates real UI state. The description adds genuine value by disclosing the return behavior (state text for indexed input, new screenshot for coordinate input), but says nothing about scroll distance defaults, bounds/clamping, or what happens if the element cannot scroll.

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 short sentences with the input modes front-loaded and the return contract second; no filler. 'Fresh screenshot coordinate' is slightly compressed phrasing that could be misread, but the sentence earns its place.

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?

With seven parameters, no output schema, and a scroll tool that changes UI state, the description covers the input/output pairing but omits scroll magnitude semantics (pages), failure behavior, and preconditions for coordinate use. Adequate but with clear gaps for a mutation-capable tool.

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

Parameters4/5

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

Schema coverage is 71% and the description meaningfully disambiguates the two parameter families, tying element_index to text output and x/y to a new screenshot. It still leaves 'pages' and the direction enum unexplained, which the schema also leaves bare, so the compensation is partial rather than complete.

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?

States a specific verb (scroll) plus the two valid resource modes: an observed element index or a screenshot coordinate. This lets an agent distinguish it from click/drag siblings at a glance, though it never says what is being scrolled (window vs element) or in what unit.

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?

Usage is only implied by the input modes: it hints that you should use element_index from an observed state or x/y from a fresh screenshot. There is no explicit when-to-use versus get_app_state, drag, or press_key, and no statement of the prerequisite that the screenshot must postdate the last UI action (that only lives in the schema).

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