Skip to main content
Glama

env_scroll

Scroll a running virtual machine's mouse wheel at a chosen pixel position: pointer moves there, positive clicks wheel down, negative clicks wheel up.

Instructions

Scroll the environment's mouse wheel: the pointer moves to the given pixel position, then the wheel turns there. Positive clicks scroll down, negative up. The environment must be running.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYespixel column to scroll at, 0-based
yYespixel row to scroll at, 0-based
nameYesname of the environment
clicksYeswheel clicks: positive scrolls down, negative up

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
logNo
nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it discloses that the pointer moves first, then the wheel turns, and explains the sign convention for scrolling direction. It does not mention potential side effects beyond the scroll, but that is acceptable for this focused action.

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 two sentences with no filler. It front-loads the core action, then provides the coordinate mechanics, direction semantics, and running-environment prerequisite efficiently.

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?

The description, combined with the fully documented input schema and an output schema, is complete enough for a simple pointer-scroll tool. It covers prerequisites and behavior; only a short explicit note about when to choose this over env_click would make it fully 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 100%, so the input schema already documents all four parameters. The description adds a bit of behavioral context around how x/y and clicks are used, but most parameter semantics already come from the schema, justifying the baseline score.

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 clearly states the tool scrolls the environment's mouse wheel and explains the coordinate-based behavior. It does not explicitly contrast itself with sibling tools like env_click, but the verb and resource are specific enough to be unambiguous.

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?

The description implies the tool is used when a scroll gesture is needed at a pixel position, and it states a prerequisite: the environment must be running. However, it gives no explicit guidance on when to prefer this over related sibling tools such as env_click or env_type.

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