Skip to main content
Glama

scroll

Move a web page by screen increments or bring a specific element into view by reference.

Instructions

Scroll the page by screens, or scroll an element into view by ref.

Input Schema

NameRequiredDescriptionDefault
refNoScroll this element into view instead.
screensNoDefault 1.
snapshotNoReturn a fresh snapshot after the action.
directionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose that scrolling may trigger lazy-loading/infinite-scroll state changes, whether the action is read-only, or how the ref/screens/direction parameters interact when both are supplied. Only the two basic modes are described.

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?

A single front-loaded sentence with no filler; both clauses earn their place by naming the two operating modes. Slightly too terse given the parameter interactions it omits.

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?

With four parameters, 75% schema coverage, no annotations, no output schema and no default direction documented, the description leaves meaningful gaps: precedence of ref vs screens/direction, default scroll direction, and what state changes scrolling triggers.

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 75%, so the schema already documents ref, screens and snapshot; the description reinforces only the ref mode. It adds nothing about direction (enum undirected in the schema) or snapshot, leaving schema baseline at 3.

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) and two resources/modes: page-by-screens and element-into-view-by-ref. The two modes are clearly separated, but it never distinguishes itself from the many other browser siblings beyond the verb.

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: pass ref to bring an element into view, otherwise scroll by screens. There is no explicit when-to-use, no precedence rule (does ref override screens/direction?), and no mention of when snapshot=true is desirable.

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