Resize the browser viewport to test responsive layouts, optionally wait for a selector, and return updated diagnostics.
Set a bounded viewport and optionally wait for a responsive-layout completion selector. Returns new diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | ||
| height | Yes | ||
| wait_for | No | ||
| session_id | Yes | ||
| timeout_ms | No |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so this is recognized as a non-destructive mutation. The description adds two useful behavioral facts beyond that: the viewport is 'bounded' and the call may optionally block on a wait condition, and it notes diagnostics are returned despite no output schema. It still omits what 'diagnostics' contains and that a session is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the primary action front-loaded and no filler. It is appropriately sized, though 'Returns new diagnostics' is vague enough to be marginally under-earning rather than precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, a nested wait_for object, 0% schema coverage, and no output schema, the description is too thin for the tool's complexity. It never explains the diagnostics payload, the timeout behavior, or the wait_for state machine, leaving real gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description carries the burden and largely fails. 'Bounded viewport' loosely covers width/height and 'wait for ... selector' loosely covers wait_for.selector, but timeout_ms, session_id, and the wait_for.state enum values (visible/hidden/attached/detached) are left completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource (set a viewport) and adds a scope qualifier ('bounded') plus the optional wait-for-selector behavior. It is clear what the tool does, though it never names or contrasts a sibling tool such as screenshot or verify_page to help disambiguate when it should be chosen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the mention of a 'responsive-layout completion selector' hints this precedes responsive verification or screenshots, but there is no explicit when-to-use, when-not-to-use, or alternative tool named. An agent must infer the workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.