set_viewport_size

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

With no annotations, the description carries the full behavioral burden and does so well. It discloses that the OS window is not resized, that Camoufox reports a frozen outerWidth/outerHeight, and that requesting a viewport larger than the launch window creates detector-readable impossible geometry. It even explains that the reply will indicate when this happens.

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 description is compact with every sentence earning its place. The core purpose is front-loaded, and the critical caveat about window geometry appears immediately after. There is no redundant or filler language.

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?

For a simple two-parameter tool with no output schema, the description covers the essential behavioral context and the main failure mode. It could be slightly more complete by referencing get_viewport_size as the read counterpart or stating value constraints, but the provided information is sufficient for correct invocation in most cases.

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%, so the description must compensate. It adds meaning by clarifying that width and height refer to viewport dimensions, not OS window dimensions, and that values too large relative to the launch window produce invalid geometry. However, it does not specify units, allowed ranges, or whether integer values are required, so the compensation is only partial.

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 opens with a specific verb+resource: 'Set the viewport width and height.' It further clarifies that this controls what the page renders and what a screenshot captures, which distinguishes it from sibling tools like get_viewport_size and browser_launch. The additional note that it does NOT resize the OS window removes a key ambiguity.

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 clear context for when this tool matters: it is 'the exact control over what the page renders and what a screenshot captures,' implying it should be used before screenshot-dependent operations. It does not explicitly name an alternative or state when not to use it, but the behavioral warning about impossible geometry effectively guides against improper use.

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