Emulate a phone, tablet or console

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

The description reveals a persistent side effect: leaving an emulated device active makes later screenshots the wrong shape, and nothing on screen obviously explains why. It also clarifies that the tool is the only way to see device-specific interface problems without owning hardware, beyond what the annotations express.

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?

The prose is economical and front-loaded: the core behavior appears first, followed by a motivating use case and a concrete workflow. The longer explanation about why mobile testing matters earns its place because it clarifies when this tool is indispensable.

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?

The description covers the main operations, the workflow, the list output conceptually, and the necessary stop cleanup. It does not fully specify the exact return shapes of list and state, but with no output schema and strong schema-level parameter descriptions, the remaining ambiguity is minor.

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?

The schema already covers all parameters with detailed descriptions, so the baseline is high. The description strengthens this by showing example ids, mentioning form factor and resolution in list output, and explaining why orientation is worth testing separately.

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 first sentence states the exact verb and resource: it resizes the Studio viewport to a real device, and the opcode enum distinguishes list/set/stop/state. It is clearly separated from sibling tools like viewport and screenshot by framing itself as device emulation.

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?

The description gives an explicit workflow: set a device, screenshot, look, then stop. It recommends pairing with playtest for running-game HUD checks, tells you to use list to find device ids, and says to stop when finished.

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