sandboxed-browser-mcp

Overview Schema Source Related Servers Discussions Admin

Scroll

browser_scroll

Scrolls the page or a scrollable panel up or down by a set number of screens, or brings a referenced element into view when you need to reveal content outside the current viewport.

Instructions

Moves the view down or up by a number of screens (the page, or a panel that scrolls on its own in the middle of the window) and returns the new view, or says the end was already reached. With a ref, scrolls that element into view. To look for something, browser_find is faster.

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

Input Schema

Name	Required	Description	Default
`ref`	No	Ref of an element to scroll to, in place of a distance (e12, f2e7 …), as browser_snapshot or browser_find showed it.
`profile`	No	Which browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.	default
`screens`	No	Distance in screens, from 0.25 to 10 (default 1).
`direction`	No	down (default) or up.	down

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.0Nov 12, 2026

addedInput schema / properties / profile

Added value: +{
+  "default": "default",
+  "description": "Which browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.",
+  "type": "string"
+}

Changed6 schema fields changedv1.1.0Oct 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / direction / default
```
Added value: +"down"
```

changedInput schema / properties / direction / description

Previous value: -"Default down"New value: +"down (default) or up."

changedInput schema / properties / ref / description

Previous value: -"Element to scroll into view instead"New value: +"Ref of an element to scroll to, in place of a distance (e12, f2e7 …), as browser_snapshot or browser_find showed it."

addedInput schema / properties / screens / default
```
Added value: +1
```

changedInput schema / properties / screens / description

Previous value: -"Default 1, from 0.25 to 10; 0.5 is half a screen"New value: +"Distance in screens, from 0.25 to 10 (default 1)."

First observedv1.0.0Oct 24, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries most of the burden and does so: it discloses the return behavior ('returns the new view, or says the end was already reached'), which is important with no output schema. It does not explain whether scrolling triggers lazy-loaded content or how far a 'screen' is measured, leaving minor gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all load-bearing: primary behavior first, mode variant second, alternative route last. No repetition of the title or filler wording.

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 zero-required-parameter tool with no output schema, the description explains both invocation modes and the end-of-content signal. The only untouched area is the profile parameter and session behavior, which the schema documents adequately on its own.

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 100%, so ref, screens, direction and profile are already documented, including that ref replaces a distance. The description adds only the effect of ref (element scrolled into view) and the idea of distance in screens, which the schema largely already conveys. Baseline 3 applies.

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 ('Moves the view down or up by a number of screens') and covers both operating modes — distance scrolling and ref-based element scrolling. The parenthetical about an independently scrolling panel clarifies scope, and naming browser_find separates it from a sibling.

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 explicit selection logic between the two modes ('With a ref, scrolls that element into view') and points to browser_find when the goal is searching. It stops short of stating when not to scroll, but the operative conditions for each parameter choice are clear.

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

Deploy Server