OmniSnap MCP

Move the viewport

scroll_to

Idempotent

Scrolls the page to reveal content outside the current viewport so screenshots and interactive annotations can cover the rest. Move by screen, position, or element, then capture again.

Instructions

Scrolls the page. Use it to see the rest of a page: annotate_interactive and the screenshots only cover what is on screen, and its "coverage" field says how much of the page that is. Scroll, then capture again. This moves the camera, not the hands: it cannot click, type or navigate.

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

Input Schema

Name	Required	Description
`y`	No	An absolute scroll position in CSS pixels.
`to`	No	"next" and "previous" move by about one screen.
`element`	No	A number from the most recent annotate_interactive on this tab. Easier and safer than retyping a selector.
`selector`	No	Scroll until this element is centred.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.3Nov 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds real value on top: it clarifies that state changes are viewport-only, that repeated scrolling is safe to retry, and it points to the "coverage" field as the way to know when scrolling is still needed. It does not say what happens when no parameter is supplied, which is the one behavioral hole.

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 short sentences, front-loaded with the action, then the workflow, then the capability boundary. Nothing is repeated and every clause carries information an agent needs.

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 four-optional-parameter, no-output-schema tool, the description covers purpose, workflow and limits well. The missing piece is default behavior when all parameters are omitted, which matters given zero required parameters.

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 description coverage is 100%, with each of y, to, element and selector documented including the "about one screen" semantics for next/previous and the reference to the most recent annotate_interactive for element. The description adds no parameter-level meaning beyond that, so the 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?

"Scrolls the page" gives a specific verb and resource, and the follow-up "This moves the camera, not the hands: it cannot click, type or navigate" draws a hard boundary against the interaction/annotation siblings. An agent can tell this apart from annotate_interactive, capture_page or hover without opening any schema.

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?

It states the triggering condition precisely (content off-screen because annotate_interactive and screenshots only cover the visible area) and prescribes the workflow "Scroll, then capture again." It also names the negative space (cannot click, type or navigate). The only gap is that it never contrasts with set_viewport, a sibling an agent could plausibly pick for viewport-related work.

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