Skip to main content
Glama

browser_extract_list

Read the rows of a long or virtualised list by scrolling its container until no new rows appear. Use this instead of browser_get_page_content whenever a page shows a repeating list longer than the viewport - mail lists (Outlook, Gmail)…

Instructions

Read the rows of a long or virtualised list by scrolling its container until no new rows appear. Use this instead of browser_get_page_content whenever a page shows a repeating list longer than the viewport - mail lists (Outlook, Gmail), invoice/billing tables, search results, transaction histories. Those UIs keep only ~7 rows in the DOM at a time, so a single page read returns a sliver and looks complete. Pass the CSS selector of one repeating row (e.g. '[role="option"]', 'tr', '[role="listitem"]'); the scrollable ancestor is found automatically. When the tab is the active one in its window, it scrolls with real wheel events, also at the bottom, so a feed that loads more rows on wheel (Threads, X) loads them. A hidden page (a background tab) gets no wheel or scroll events, IntersectionObserver callbacks or animation frames, so a list that loads or renders rows while you scroll stops at what is already there; then reached_end is false and note says why. Returns deduplicated row text, scroll_method (wheel or script) and reached_end, which is true only when the list stood at its bottom in a visible page with no new rows, growth or movement for stable_rounds rounds in a row. If the selector matches no rows with text, the answer is error "no-rows".

Input Schema

NameRequiredDescriptionDefault
wait_msNoWait after each scroll so new rows can render (default 350)
max_rowsNoStop after this many unique rows (default 500, max 5000)
selectorYesCSS selector matching ONE repeating row (e.g. '[role="option"]' in Outlook, 'tr' in a table)
containerNoOptional CSS selector for the scrollable container. Omit to auto-detect the row's nearest scrollable ancestor.
scroll_stepNoPixels per scroll. Omit for 85% of the container height.
stable_roundsNoRounds in a row with no new rows, growth or movement before stopping, and at the bottom before reached_end (default 3)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.30.2
    • changedInput schema / properties / stable_rounds / description
      Previous value: -"Consecutive scrolls with no new rows before stopping (default 3)"New value: +"Rounds in a row with no new rows, growth or movement before stopping, and at the bottom before reached_end (default 3)"
  2. Addedv1.28.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the wheel-vs-script scroll method, the hidden/background-tab limitation (no wheel events, IntersectionObserver callbacks or animation frames, so reached_end is false and 'note' explains why), deduplication of row text, and the error case ('no-rows'). This is unusually rich behavioral disclosure well beyond what a bare schema conveys.

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 purpose and the alternative, then progressively deeper behavior. It is long but nearly every sentence carries distinct information (scroll method, tab visibility effects, return fields, error code). Dense rather than padded, though the volume is at the upper edge of what is needed.

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 exists, so the description must explain return values, and it does: deduplicated row text, scroll_method (wheel or script), and reached_end semantics (true only at the bottom of a visible page after stable_rounds of no growth). Combined with the error case and hidden-page caveat, an agent has everything needed to call and interpret results correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains what the selector must match (one repeating row, with per-site examples) and that the container's scrollable ancestor is auto-detected when omitted. The reached_end/stable_rounds coupling is also clarified, tying a parameter to an output semantic.

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?

States a specific verb and resource ('Read the rows of a long or virtualised list by scrolling its container') and explicitly scopes it to a class of page. It directly distinguishes itself from the sibling browser_get_page_content, so an agent can choose between them 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?

Explicitly names the alternative ('Use this instead of browser_get_page_content whenever a page shows a repeating list longer than the viewport') and gives concrete trigger examples (Outlook, Gmail mail lists, invoice tables, search results, transaction histories). It also explains why the alternative fails (~7 rows in DOM), which is exactly the routing rationale an agent needs.

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