Skip to main content
Glama

set_device

Switch browser device emulation between mobile and desktop modes. Recreates viewport, user agent, and touch settings while preserving cookies and localStorage.

Instructions

Switch browser device emulation between mobile and desktop modes. Recreates the browser context with new user agent and touch settings. Mobile presets emulate an exact viewport; desktop-class presets resize the real browser window (headed mode), so the page keeps following manual window resizes. 'desktop' imposes no size. Cookies and localStorage are preserved. Use preset device names for convenience or provide custom parameters. Returns page_state showing the page as rendered in the new device mode. Cannot be used while sub-agents are running.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deviceNoDevice preset name: 'iphone_15', 'iphone_se', 'iphone_15_pro_max', 'pixel_7', 'galaxy_s24', 'ipad_pro', 'ipad', 'galaxy_tab_s9', 'desktop', 'desktop_hd'. Use 'desktop' to reset to default mode. Cannot be combined with custom fields.
hasTouchNoEnable touch event support. Cannot be used with 'device'.
isMobileNoEnable mobile viewport behavior. Cannot be used with 'device'.
viewportNoCustom viewport dimensions. Cannot be used with 'device'.
userAgentNoCustom user agent string. Cannot be used with 'device'.
deviceScaleFactorNoDevice pixel ratio (e.g., 2 for retina, 3 for iPhone). Cannot be used with 'device'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are present, so the description carries the full burden. It discloses that the browser context is recreated, cookies and localStorage are preserved, desktop-class presets affect the real window, and it returns page_state. It also warns about the sub-agent limitation.

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?

The description is dense but each sentence adds a distinct fact: purpose, context recreation, preset behavior, preservation, custom vs preset usage, return value, and constraint. It is front-loaded with the main purpose and follows a logical order with no filler.

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 6-parameter tool with no annotations and no output schema, it explains return value, side effects, and constraints. The only minor gap is not explicitly stating what happens to the current page (e.g., whether it reloads), though 'recreates the browser context' strongly implies it.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining preset behavior ('Mobile presets emulate an exact viewport; desktop-class presets resize the real browser window...') and clarifies that 'desktop' imposes no size. It also gives guidance on choosing presets vs custom fields.

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: 'Switch browser device emulation between mobile and desktop modes.' There are no sibling tools with the same purpose, and the description clearly differentiates this from navigation, scrolling, and other browser action tools.

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?

Provides clear context for when to use preset names vs custom parameters, and distinguishes mobile vs desktop behavior (exact viewport vs real window resize). It also discloses a hard constraint ('Cannot be used while sub-agents are running'). Though it doesn't compare with alternatives, no sibling tool serves the same function.

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