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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful behavior: the severity taxonomy (high/medium/low/info) and the semantic of viewport.deviceWidthPx vs layoutWidthPx as the responsiveness test. It stops short of runtime cost or how heavy a 12-device run is.

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 tight paragraphs with the core purpose front-loaded, then severity definitions, then the usage/handoff guidance. Dense but every sentence carries information; slightly long but no filler.

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 14-parameter, no-output-schema tool, the description adequately explains what is reported, the severity levels, and the responsiveness criterion, so an agent can interpret results. It could say more about runtime expectations across many devices, but nothing essential is missing.

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%, so the schema already documents all 14 parameters, establishing the baseline of 3. The description corroborates a few (media queries, overflow selector) and clarifies output semantics, but adds little parameter-level meaning beyond the schema.

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 specific verb+resource: opens a URL across multiple screens and reports only responsive problems (overflow, clipped text, tap targets, viewport meta, media queries). It explicitly excludes images and names the failing-device handoff to screenshot_on, so an agent can distinguish it from siblings without opening a schema.

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 clear when-to-use (verifying a redesign, finding broken breakpoints) and a concrete follow-up alternative (screenshot_on on the failing device). It does not address the session-based siblings (open_responsive_session/observe_responsive_session), so the alternative routing is incomplete but the positive guidance is strong.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutation nature is covered. The description adds meaningful detail beyond that: exactly what is torn down (paginas, contextos, servidor del panel visual) and what survives (capturas guardadas permanecen en disco), which is precisely the kind of side-effect context an agent needs before calling a cleanup tool.

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 short sentences, each earning its place: what is freed, when to call it, and what persists afterward. The core action is front-loaded in the first clause with no preamble or repetition.

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 one-parameter teardown tool with no output schema, the description covers the action, the recommended timing, and the persistence caveat. Only edge behavior (calling with an unknown or already-closed sessionId, and whether a confirmation is returned) is left unspecified.

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?

There is a single sessionId parameter with 100% schema description coverage, and the schema already explains its origin and lifetime ('ID devuelto por open_responsive_session'). The prose adds nothing about the parameter, so the baseline 3 applies.

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 ('Cierra una comparacion responsive completa') and spells out the concrete effect: it releases the session's pages, contexts and server from the visual panel. It is unambiguously the teardown counterpart to open_responsive_session, and no other sibling in the list closes a session.

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?

It gives explicit when-to-use guidance ('Usa esta herramienta al terminar para no acumular navegadores') with a stated rationale. It stops short of naming alternatives or stating what happens if the session is already closed or the id is invalid, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral content by enumerating the returned facts (browser, capture destination, screen count), which the annotations don't provide. It doesn't mention staleness of the data or any prerequisites, so it stays at a solid 3.

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?

Two short sentences with no filler: the first lists what is reported, the second gives the usage cue. It is front-loaded and efficient, though the second sentence is a soft suggestion rather than something an agent can act on precisely.

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 input parameters and no output schema, the description carries the burden of hinting at the response shape, which it does by naming the three returned facts. That's sufficient for an agent to call it and interpret the result, though richer detail on the returned structure would help.

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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related the description needs to compensate for, and schema coverage is trivially 100%.

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 specific verb (reports) and three concrete outputs: which local browser drives the emulation, where screenshots are stored, and how many screens are available. It's clear what the tool returns, but it never names or distinguishes itself from siblings like list_devices or list_responsive_sessions, which could also look status-related.

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?

"Usala para diagnosticar antes de culpar a la pagina" gives an implied usage context (troubleshooting before blaming the page), but it doesn't state when-not to use it or point to any alternative tool. The guidance is directionally useful but incomplete.

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

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.

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

Adds real context beyond the openWorldHint/readOnlyHint annotations: state persists between calls, semantic locators are preferred because the DOM varies by viewport, and failures are returned per screen. Missing detail on partial-failure semantics (does the batch abort?) and timeouts.

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?

Dense but well front-loaded: execution scope comes first, then state persistence, locator strategy, targeting advice, and the follow-up tool. A couple of sentences could be trimmed but nothing is wasted.

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 batched-action tool with no output schema, reporting per-screen failures is helpful and the observe_responsive_session pointer closes the loop. However, step execution order, failure handling, and return shape for successes remain unexplained.

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 coverage is 67% and the description only adds the screenId='all' default (already in the schema) plus the sessionId lineage from open_responsive_session. The 17-value action enum and the 40-item step cap are left entirely to the schema, so the description adds little parameter meaning.

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 specific verb and resource ('Ejecuta pasos en una pantalla o repite la secuencia en todas'), including the cross-screen broadcast mode. It is distinguishable from navigate_responsive_session and observe_responsive_session, though it does not name the closest sibling interact_on.

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 guidance: use screenId='all' to repeat across screens, target a specific screenId when a menu only exists on mobile, and call observe_responsive_session afterward to inspect results. No explicit 'when not to use' or pointer to interact_on/navigate_responsive_session.

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

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuine lifecycle semantics beyond them — sessions persist their state across calls and vanish when the server is stopped. It also previews the returned fields, which is more than the annotations provide. It does not mention ordering or size limits, so not a 5.

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?

Two sentences, front-loaded with the core action and then the payload/lifecycle details. Dense but every clause carries information; only the field list is slightly list-heavy.

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 compensates by naming the fields returned, and it explains persistence for a stateful session tool. It omits ordering, pagination/limits, and what an empty list means, so it is complete but not exhaustive for a zero-param read tool.

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 tool takes zero parameters, so the baseline is 4; however, the description's field enumeration ('sessionIds, screenIds, tamaños, URLs actuales, enlace al panel') is really about return values rather than parameters. With no parameters to disambiguate and no output schema, this is adequate but adds nothing parameter-specific, landing at 3.

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 specific verb and resource ('Lista las comparaciones responsive abiertas') and enumerates what each entry contains (sessionIds, screenIds, tamaños, URLs, enlace al panel). It is clearly distinguishable in kind from the session-manipulating siblings, but it never names a sibling (e.g. observe_responsive_session) to route the agent, so it stops short of full differentiation.

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?

There is no explicit when-to-use, when-not-to-use, or named alternative. The only contextual cue is the scoping phrase 'abiertas en este proceso MCP', which implies the tool is for surveying the current process's sessions but does not tell an agent when to prefer it over observe_responsive_session or check_responsive.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description goes further by disclosing that contexts, cookies, and sizes are preserved across screens and that results are returned per screen with errors surfaced rather than hidden partial failures. That partial-failure disclosure is genuinely useful for a multi-screen mutation. It stops short of noting session prerequisites or side effects.

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 compact sentences with the core action front-loaded and no filler. The reload tip and the return-value sentence are each earning their place, though the third sentence is slightly informational rather than directive.

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 summarizes the return shape (per-screen results plus errors) and covers the session/url inputs adequately. Missing only minor detail such as expected failure modes or whether navigation is blocking across screens.

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 coverage is 50% (only sessionId is documented, and its lifecycle text duplicates the description's session context). The description compensates only lightly for the undocumented url parameter by noting that re-passing it triggers a reload, without adding format or constraint details.

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 specific verb (navigate) and resource (all screens of a comparison) with a clear scope modifier (same URL, preserving contexts/cookies/sizes). It is distinguishable from siblings like observe_responsive_session or interact_responsive_session, though it never explicitly names or contrasts them.

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?

Provides one concrete usage hint -- re-pass the URL to reload all screens after changing code -- which implies when to call it again. However, it never states when to use this versus observe_responsive_session or interact_responsive_session, leaving the choice to inference.

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

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

Annotations only cover readOnlyHint and openWorldHint. The description adds real behavioral context the annotations lack: it does not reload the page, it persists one PNG per viewport size, and it returns status/URLs/recent console and network events. It does not disclose where screenshots are written or any rate/size limits, so it falls short of a 5.

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?

Two dense sentences: the first front-loads the core behavior and return payload, the second enumerates the opt-in flags. No filler, though the flag list could be tighter.

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 covers the return shape (PNGs, status, URLs, console/network events) and three of the five flags. The gaps are fullPage semantics and explicit guidance on choosing this tool over siblings.

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 coverage is only 20% (5 params), so the description must compensate. It usefully explains dom (accessibility tree), audit (layout review) and returnImages (inline screenshots), but says nothing about fullPage, and sessionId's meaning lives only in the schema.

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 specific verb and resource ('Observa las pantallas abiertas'), plus concrete outputs (PNG per size, status, URLs, console/network events). The 'sin recargarlas' qualifier distinguishes it from navigate_responsive_session and interact_responsive_session, though it never names a sibling 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?

Implies usage via 'sin recargarlas' (observe without disturbing the page) and explains what each optional flag unlocks. However, it gives no explicit when-to-use/when-not guidance and never contrasts itself with check_responsive or the other session tools, leaving routing to inference.

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

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

Annotations only say readOnlyHint=false and openWorldHint=true, so the description carries real weight and delivers: pages persist between MCP calls, each screen keeps independent web state, screenshots refresh every 3 seconds, and no iframes or security-header stripping are needed. These are meaningful behavioral traits beyond the annotations, though it omits resource/lifecycle limits (e.g. max sessions, cleanup).

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 core action and its payoff (dashboardUrl with live side-by-side screenshots) are front-loaded, and each sentence adds information. It is dense but not padded, though the trailing note about iframes/headers is somewhat incidental.

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?

There is no output schema, and the description usefully enumerates the return values (sessionId, screenIds, dashboardUrl), which covers the response side. But for a stateful, mutating session-creating tool, the undocumented input parameters leave a clear gap in what an agent needs to call it correctly.

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% across four parameters, and the description does not compensate: url, locale, devices (array, 1-6 items) and colorScheme are never explained. 'Various sizes' only loosely gestures at devices, leaving the agent to infer the meaning and format of every input.

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: it opens the same URL at multiple viewport sizes and creates a persistent session, returning sessionId, screenIds and a dashboardUrl. This is clear enough for an agent to distinguish it from list/observe/navigate siblings, though it does not explicitly name an alternative it is not.

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?

Usage is implied (open a session first, then pages persist across MCP calls), and it hints at the advantage over one-off screenshot tools. However it never states when to prefer it over siblings like check_responsive, preview_devices or screenshot_on, nor any prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: one PNG per device including horizontal overflow, a parallelism cap of 4, and the default device set. It omits auth/permission requirements and rate limits, keeping it short of a 5.

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?

Four sentences, front-loaded with the core action, then output, then default behavior, then the routing alternative. Each sentence carries distinct information with no filler.

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 13-parameter tool with no output schema, the description covers the return value (PNG per device plus overflow), the default device behavior, and the sibling alternative. Parameter details are fully carried by the 100% schema coverage, so the only minor gap is that permissions/auth context is not mentioned.

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%, so the baseline is 3. The description earns above that by naming the concrete default device ids (iphone-15-max, galaxy-s24, ipad-pro-11, laptop, desktop-hd) and restating the 'up to 4 in parallel' constraint tied to concurrency, adding meaning the schema only alludes to.

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 specific verb and resource ('Captura la MISMA URL en varias pantallas') plus the output (un PNG por dispositivo con el desborde horizontal). It explicitly differentiates from sibling check_responsive and implicitly from screenshot_on by contrasting scope.

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 the exact use-case question it answers ('como se ve esto en movil, tablet y desktop') and names the alternative check_responsive with the condition that selects it (only need to know where the layout breaks, no images downloaded). Nothing is left to inference.

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

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

With readOnlyHint/openWorldHint already declared, the description adds real context: the PNG is written to captures/, a responsive audit runs in the same viewport and its findings are returned alongside the path, and returnImage is flagged as token-expensive. It doesn't mention network/permission caveats, but the token-cost warning and artifact-location disclosure go beyond the annotations.

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?

Front-loaded with the core action and artifact location, then the audit behavior, then call examples and the returnImage caveat. Four dense sentences with little waste, though the mixed Spanish/enum tokens make it slightly denser than ideal.

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?

Given 15 parameters, nested viewport/geolocation objects, and no output schema, the description does the necessary work of stating the return shape (PNG path in captures/ plus audit findings) and the expensive optional image path. It stops short of explaining how its viewport audit relates to the dedicated responsive siblings.

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% across all 15 parameters, so the schema already carries the bulk of the semantics and the 3 baseline applies. The description adds marginal value by showing typical request shapes, pointing at list_devices for device ids, and clarifying the token cost of returnImage.

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 specific verb and resource: opens a URL in the local browser emulating ONE concrete screen and saves a PNG, plus runs a responsive audit. The emphasis on 'UNA pantalla' implicitly differentiates it from multi-screen siblings, but no sibling is named, so the contrast is left to inference.

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?

Provides concrete call shapes ({ url, device: "iphone-15-max" } and { url, viewport: {...} }) which imply usage, and warns to set returnImage=true only when the image is actually needed. However, it never says when to pick this over check_responsive, preview_devices or the session-based siblings, so the routing decision is left implicit.

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