Drive a flow on an emulated screen

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true), disclosing failure semantics ('se detiene en el primer paso que falla salvo continueOnError'), the no-session-persistence constraint, and the non-obvious coordinate-fallback for click/tap when the layout overflows the device width, including the 'via' field it returns. This is exactly the behavioral context an agent needs.

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?

Purpose and the session constraint are front-loaded, and the example is compact; but the action list partly duplicates the schema enum and the coordinate-fallback paragraph is dense. Most sentences earn their place, with some redundancy.

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 complex nested tool with 9 params and no output schema, it covers the essentials: step structure, failure behavior, session limitation, and the coordinate-fallback quirk. It never describes the return shape (screenshot paths, step results) beyond the 'via' field, which is the main remaining gap.

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?

At 67% schema coverage the description adds real meaning: the { action, ...args } step contract, the accepted locator kinds, the example step array, and the continueOnError semantics. It does not cover several top-level params (device, locale, viewport, colorScheme, finalScreenshot) beyond what the schema states, so it is strong but not exhaustive.

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?

States a clear verb and resource: 'Ejecuta una secuencia de pasos en UNA pantalla emulada dentro de la misma sesion de navegador'. The enumeration of supported interactions and the note that no session persists between calls implicitly separates it from the open_/observe_/interact_responsive_session family, but no sibling is named explicitly.

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?

Gives concrete when-to-use context: 'Es la tool para probar flujos (login, checkout, menu hamburguesa, scroll) y verificar que el resultado se vea bien en ese dispositivo'. The 'no podras mantener una sesion entre llamadas: mete todo el flujo en una sola invocacion' constraint is valuable routing guidance, though no alternative tool is named for the when-not case.

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