List Roblox OS windows

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is partly redundant. The description still adds real context the annotations cannot: Windows-only execution, the underlying PowerShell query, that the result is empty when no windows are open, cost=low, and a failure route to tool-schema. Missing only rate/timeout behavior.

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 what/why is front-loaded in the first two sentences and the return shape follows immediately. The metadata footer (Phase, cost, idempotency, Requires, Produces, Safety, On failure) is somewhat boilerplate and restates the annotations, but it is compact and consistently formatted.

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?

No output schema exists, but the description supplies the return contract ({ windows: [{ pid, title }] }, empty if none). Combined with the Windows constraint, failure guidance, and read-only safety, an agent has everything needed 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?

Zero parameters, so the baseline of 4 applies; the explicit 'Signature: {}' confirms no arguments are accepted. There is no parameter semantics to describe beyond that.

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 (list), resource (Roblox player processes on the SERVER host), and scope constraint (own a visible OS window), plus the exact implementation path (PowerShell Get-Process RobloxPlayerBeta with non-empty MainWindowTitle). This is precise enough to distinguish it from screenshot-window and every other listing sibling.

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 an explicit trigger: 'Use this before screenshot-window when more than one Roblox window may be open, to pick the right processId.' That names the alternative tool and the exact condition that selects it, leaving nothing to inference.

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