Skip to main content
Glama
Sign In
agent-bridge

agent-bridge

by avas-app
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

screen.scroll

screen_scroll

Scrolls the nearest ScrollView, FlatList, or FlashList and waits for rendering; can bring a target into view, jump to start/end, or scroll by an offset.

Instructions

Scroll the nearest ScrollView/FlatList/FlashList, then wait for the render. Takes a target (or {to: target}) to bring into the middle of its scrollable, {toEnd:true}, {toStart:true}, or {by: points} (negative scrolls back); the last argument may be {within: target, index} to name the scrollable (a target inside it, or its testID). Without a target it scrolls the largest scrollable on screen. Only rendered elements can be targeted: rows a FlatList has not rendered yet need {toEnd:true} or {by} first. Returns the offset and, for a target, whether it is now on screen. target is a string (testID, label, placeholder or text) or an object that must match every key it sets: {testID, label, placeholder, text, at:[x,y], index}. Unknown keys are errors. {at:[x,y]} hits the smallest element covering that point, for icon-only buttons with no label. Several matches: add an index, either in the target or as a trailing {index:n} argument.

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": "screen_scroll"
  }
}

Input Schema

NameRequiredDescriptionDefault
argsNoThe tool's arguments, in order (each any JSON value). Leave out for none.
fullNoReturn a result over 32 KB whole instead of a summary of its size and shape.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses the implicit wait-for-render, the return value (offset plus on-screen status), and that unknown target keys are errors. It stops short of describing failure modes for missing or ambiguous elements beyond the index hint, and gives no timing/timeout behavior.

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?

The scroll action and default behavior are front-loaded and every clause carries semantics an agent needs. It is a dense run-on block with heavy inline brace notation, though, which costs some scannability.

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?

For a complex, no-output-schema tool the description covers action, argument grammar, matching rules, and return values, which is close to sufficient. Missing are error/timing behavior when a target is not found or never becomes visible.

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

Parameters5/5

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

The input schema is only a generic args array plus full, so the real argument grammar exists nowhere but the description. It enumerates the target forms (string vs object), the shape keys {testID, label, placeholder, text, at:[x,y], index}, the argument modes {to}, {toEnd}, {toStart}, {by}, the {within, index} scoping, negative-by semantics, and point-hit behavior for icon-only buttons.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource plus the exact component types affected ("Scroll the nearest ScrollView/FlatList/FlashList, then wait for the render"), which no sibling like screen_press or screen_findText does. An agent can tell immediately what this tool does and what it acts on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete conditions: use {toEnd:true} or {by} when a FlatList has not rendered the rows yet, and it explains the no-target default (largest scrollable on screen). It does not explicitly contrast with siblings such as screen_findText or screen_waitFor, so routing between tools is left partly to inference.

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