List emulated screens

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. Beyond that, the description adds genuinely useful behavior: the returned ids are consumed by the other tools, arbitrary Playwright catalog names are accepted as ids, and appending ' landscape' forces landscape orientation. It does not mention error behavior or result size, but the added context is substantive.

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?

Three sentences, front-loaded with the core purpose and return value, followed by usage guidance and the landscape/Playwright tips. No filler, though the parenthetical device enumeration is slightly redundant with the schema enum.

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 no output schema, the description correctly takes on the burden of explaining what is returned ('ids de pantallas') and how those ids are used downstream. Combined with the landscape suffix and catalog-name behavior, an agent has enough to call and use the tool, though the overlap with 'preview_devices' is left unresolved.

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 100% for both parameters (group enum and query text search), so the schema already carries parameter meaning. The description loosely maps to the group enum ('telefonos, tablets, laptops, desktops') but adds no syntax or format detail beyond the schema — and even introduces 'laptops', which is not in the enum. Baseline 3 is appropriate.

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 states a specific verb and resource ('Devuelve los ids de pantallas que aceptan las demas tools') and clarifies the scope (phones, tablets, laptops, desktops with viewport, DPR, mobile, touch). It positions itself as the entry-point lookup relative to other tools, but never explicitly differentiates itself from the sibling 'preview_devices', which appears to overlap in purpose.

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?

Explicit when-to-use guidance is given: 'Usa primero esta tool si no sabes que dispositivo pedir.' It also offers an alternative path (any Playwright catalog name such as 'iPhone 12' works directly), which tells the agent it can skip this call when it already knows the device. No when-not-to-use rule or contrast with 'preview_devices' is provided.

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