Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_scroll

Scroll a page or a specific region to reveal below-the-fold content and lazy-loaded sections, and detect scroll locks before auditing or judging missing UI.

Instructions

Scroll like a user — real apps hide their bugs below the fold. Reports the resulting position (px and %), and explicitly flags SCROLL LOCKED: scrollable content exists but the page will not move (the classic leaked modal scroll-lock that silently cuts users off from everything below the fold — snapshots also detect this passively as an OVERLAY line). Without target it scrolls the page, falling back to the largest scrollable pane on app-shell layouts. Pass target to scroll ONE region instead (a sidebar nav, a dialog body, a table pane): the page-level pick is the LARGEST scroll port, so a smaller region beside it never moves and its content looks truncated when it is only scrolled away — never call a nav item missing without scrolling its own container first. Use before judging a long page: the design audit measures at the current scroll position, so scroll + re-snapshot/re-audit deep sections; scroll also triggers lazy-loaded content whose failures then surface as oracle violations.

Input Schema

NameRequiredDescriptionDefault
byNoScroll by px instead (positive = down). Default 600 when neither given.
toNoJump to an edge
targetNoScroll ONE region instead of the page: "testid=…", "text=…" or "label=…". Scrolls that element's nearest scrollable ancestor.
sessionNoTarget this session directly instead of the active one — pass it explicitly when dispatching to MULTIPLE sessions in one turn (e.g. two scout_click calls with different `session`), which then run CONCURRENTLY rather than queueing. Omit for single-session sequential use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.31.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

No annotations exist, so the description carries the load and does it well: it discloses the return payload (px and %), the SCROLL LOCKED flag with its cause, the OVERLAY cross-reference, and that scrolling triggers lazy-loaded content whose failures surface as oracle violations. It stops short of stating timing/settle behavior or what happens if the target has no scrollable ancestor.

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?

Front-loaded with the purpose and the key failure mode, then target semantics, then the workflow rule. Several long parenthetical digressions about leaked modals and truncated nav content are dense but mostly earn their place; a tighter edit would cut roughly a fifth.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and the description nevertheless explains what comes back (px and % plus the scroll-locked flag). For a 4-parameter, zero-required navigation tool, everything needed to call it correctly and interpret the result is present.

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 100%, so a 3 is the floor, but the description earns more by explaining the consequence of target: it scrolls the element's nearest scrollable ancestor and exists precisely because the page-level pick is the largest scroll port. That semantic linkage (why a smaller region appears truncated) is not in the schema.

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?

Names a specific verb and resource ('Scroll like a user') and immediately scopes it against the passive alternative — snapshots detect scroll-lock, this tool actively scrolls. An agent can distinguish it from scout_snapshot and scout_design_audit without opening either schema.

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

Usage Guidelines5/5

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

Explicit sequencing rules: use before judging a long page, scroll then re-snapshot/re-audit, and 'never call a nav item missing without scrolling its own container first.' It also states when to omit target (page-level default with app-shell fallback) versus when to pass it.

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