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

Annotations already establish readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds the returned fields and pagination via cursor, which is useful, but the Mac Meta/Command shortcut line describes keyboard behavior unrelated to listing apps and adds no transparency about this 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?

The first sentence conflates purpose, returned fields, use case, fallback, and platform behavior into one long clause, and the Mac Meta+C sentence does not earn its place for a listing tool. The parameter line is compact and front-loaded enough to be usable, but overall structure is loosely organized.

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, so the description correctly enumerates return fields, and it covers purpose, consumer tool, fallback, and pagination. All three parameters are addressed, making it nearly complete for a simple read-only listing tool, with the only gap being detailed field-path availability.

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, and it largely does: response_detail is given allowed values (summary|compact|full), fields is described as dotted paths, and cursor as next page. This meaningfully exceeds the bare schema, though it defers detail to 'server instructions' rather than fully documenting available field paths.

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 identifies the resource and scope precisely — the apps open on the user's computer — and enumerates the returned fields (hwnd, title, app, whether in front), which differentiates it from listing tools like ws_ls. It also names the consuming sibling screen_open_app, though the purpose is expressed as a fragment rather than a crisp verb+resource statement.

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 states the downstream use case ('to pick one for screen_open_app') and a clear fallback when no match exists ('ask the user to open it'), which is genuinely actionable guidance. It stops short of explicit when-not-to-use or naming alternatives to screen_open_app, so it falls short of a 5.

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