OmniSnap MCP

Show the page at another width

set_viewport

Idempotent

Holds the page at a phone, tablet, or desktop width so later audits, maps, and measurements target that viewport; reset restores the page’s real size.

Instructions

Holds the page at a phone, tablet or desktop width, and leaves it there. Every tool afterwards, including the numbered map, the accessibility audit and the measurements, then answers about that width, which is how you find what is wrong at 375px rather than just noticing that something is. Call it with reset to give the page back. Chrome shows a debugging banner while this is held; that is Chrome, not the page.

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

Input Schema

Name	Required	Description
`reset`	No	Hand the page back at its real size.
`width`	No
`height`	No
`preset`	No	375, 768 or 1440.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.3Nov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare non-readOnly, idempotent and non-destructive, and the description adds genuinely non-obvious behavior: the viewport persists and changes what every later tool reports, plus the Chrome debugging banner caveat so the agent doesn't misattribute it to the page. It stops short of stating whether the setting is per-tab or survives navigation.

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 core effect, then consequence, then undo path, then caveat — a sensible order. A few conversational phrases ('rather than just noticing that something is') could be trimmed without losing meaning.

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?

No output schema exists, and the description covers the state change, the persistent effect on sibling tools, the reset escape hatch and the banner caveat, which is enough for a 4-parameter tool. The only gap is scope of persistence across tabs or reloads.

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 50%; the enum and reset already document themselves in the schema. The description reinforces reset and the meaning of width ('375px', 'phone, tablet or desktop'), but leaves height and the relationship between preset and explicit width/height unexplained, so it only partly compensates.

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 action (holding the page at a chosen viewport width) and its persistent scope ('leaves it there'), and immediately explains the downstream consequence for other tools. An agent can distinguish this from capture_page or set_color_scheme 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?

Gives a clear motivating condition — reproducing what breaks at 375px rather than merely noticing it — and explicitly tells the agent to call it with reset to release the page. It does not name explicit when-not conditions or an alternative sibling, but the usage context is unambiguous.

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