List Displays

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the useful detail that coordinate spaces are included in the result, but does not explain the format or whether the display order or identifiers are stable across calls. No contradiction with 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?

The description is a single, focused sentence with no redundant words. It states the action and the key output in eight words, which is ideal for an agent to parse quickly.

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 simple read-only, idempotent, zero-parameter list operation, the description gives enough context. It identifies the domain (displays) and the meaningful output (coordinate spaces). Without an output schema, a bit more detail about the exact shape of the output could help, but the risk of incorrect invocation is very low.

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 has zero parameters, so parameter semantics are not a concern. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description adds no misleading parameter information.

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 clearly identifies the verb ('List') and resource ('attached displays'), and specifies what is returned: their coordinate spaces. It is easy to distinguish from sibling tools like list_windows and list_apps because it explicitly targets displays.

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?

The tool's zero-parameter nature makes usage straightforward, and the description implies it should be used when an agent needs to know available displays and coordinate systems. It does not explicitly name alternatives or exclusions, but the clarity of the resource makes misuse unlikely.

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