Skip to main content
Glama

browser_scroll

Scrolls the browser viewport by wheel deltas, or centers a referenced element when a ref is provided. Use it to bring off-screen content into view for inspection or interaction.

Instructions

Desplaza con la rueda del ratón (dy>0 baja). Con ref, lleva ese elemento al centro.

Input Schema

NameRequiredDescriptionDefault
xNoCoordenada X en píxeles CSS del viewport
yNoCoordenada Y en píxeles CSS del viewport
dxNo
dyNo
refNoRef de un elemento devuelto por browser_snapshot/browser_find (ej. 12 o "f1:7" en iframes)
snapshotNoSi true, devuelve el snapshot tras la acción (ahorra un turno)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full disclosure burden. It usefully adds wheel-direction semantics for dy and explains that a ref centers the target element — behavior not present in the schema — but it omits whether scrolling is synchronous, what page state changes occur, and any permission or waiting requirements.

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, front-loaded sentences with no filler; the direction rule and ref behavior are stated immediately. Only slightly under-specified rather than bloated.

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?

For a six-parameter, annotation-free tool with no output schema, the description covers dy direction and ref centering but says nothing about the snapshot shortcut, coordinate params, or what the call returns. Adequate but with clear gaps an agent would need to infer.

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 67%, so the schema already documents x, y, ref, and snapshot. The description adds real meaning for the undocumented dy (direction) and clarifies ref as a centering target, but leaves dx, x, and y semantics untouched. A 3 reflects partial compensation for the coverage gap.

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 (Desplaza) and resource (rueda del ratón), with the added refinement that dy>0 scrolls down and that a ref centers that element. This clearly identifies it as a scroll tool, though it does not explicitly name sibling tools like browser_move or browser_cursor to differentiate.

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 usage via 'dy>0 baja' and the optional ref-centering behavior, giving the agent directional context. However, it never states when to choose this over alternatives (e.g., browser_move for pointer movement) or any prerequisites/exclusions.

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