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

No annotations are provided, so the description bears the full behavioral burden. It usefully discloses the underlying mechanism ('uses hyprctl activewindow geometry'), which implies a Hyprland dependency, but it does not mention side effects (e.g., whether a capture file is saved), permissions, or error behavior when no window is focused.

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?

A single front-loaded sentence with zero waste. The parenthetical adds concrete implementation context without diluting the primary action.

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 zero-parameter screenshot tool, the description covers the action and its mechanism, and the output schema handles return values. The only meaningful gap is the absence of any safety or side-effect disclosure, but the tool's simplicity keeps this from being a severe omission.

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 and the schema is empty, so the baseline score of 4 applies per the rubric. There are no parameters whose semantics need additional explanation.

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 ('Screenshot') and a precisely scoped resource ('currently focused window'). The 'currently focused' qualifier implicitly distinguishes it from sibling tools like capture_window (a specific window) and capture_monitor (a full monitor), so an agent can select it without opening other schemas.

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 description gives no explicit guidance on when to use this tool versus capture_window, capture_monitor, or capture_region. It also omits any prerequisites or exclusions, leaving the agent to infer selection criteria from the name alone.

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 no annotations, the description carries the full behavioral burden. It usefully discloses the default-focus behavior and that a file lands on disk (via `path`), but says nothing about screen-recording permissions, side effects on existing captures, or interaction with cleanup_captures.

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, zero filler, and the core action plus the key default are front-loaded before the return-value note. Nothing could be cut without losing information.

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?

An output schema exists, so return-value detail is not required, and the description wisely points at `path` anyway. Still, for a capture tool with no annotations it omits permission prerequisites and capture lifecycle context that an agent would need to call it reliably.

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 0% and `name` has no in-schema description, so the description must compensate. It does explain the omission semantics clearly, but never states what a valid monitor name looks like or where to obtain one, leaving half the semantic gap open.

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 ('Screenshot a full monitor'), and the scope word 'full monitor' implicitly separates it from capture_window and capture_region siblings. It does not explicitly name an alternative, so it falls just short of the top band.

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 one useful conditional: omitting `name` captures the focused monitor, which is real usage guidance. However, it never says when to prefer this over capture_region, capture_window, or capture_active_window, nor that list_monitors is the way to discover valid names, so guidance is only implied.

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?

No annotations are provided, so the description carries the full burden. 'Global compositor coords' is a useful hint about the coordinate space, but it says nothing about permissions, whether overlays/HiDPI scaling are handled, out-of-bounds behavior, or what the capture returns.

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?

A single tight sentence with the coordinate-space constraint front-loaded. No wasted words.

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?

An output schema exists so return values need not be explained, but with four required params at 0% schema coverage and no annotations, the description should cover coordinate conventions and boundary behavior. It is too thin for the tool's complexity.

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 0% for all four required params. 'Arbitrary rectangle' and 'global compositor coords' imply x/y origin and w/h extent, but the origin corner, pixel units, and handling of negative or out-of-range values are never specified.

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 (Screenshot) and resource (arbitrary rectangle), and the phrase 'arbitrary rectangle' implicitly separates it from the monitor/window siblings. It does not name those siblings or explicitly contrast the scope, so it lands just short of a 5.

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 when-to-use guidance and no alternatives named. The reader can infer it is used when you want a free-form region rather than a full monitor or window, but that inference is left entirely to the agent.

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 no annotations, the description carries the full burden, and it does disclose real behavior: case-insensitive matching on class or title, and the 'largest match wins' tie-break rule. It is silent, though, on what happens when nothing matches, whether the window is raised/focused, or any screen-capture permission requirements.

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, front-loaded with the action and the matching rule, with zero filler. Nothing could be removed without losing information.

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?

An output schema exists, so return values need not be explained, and the param semantics plus disambiguation rule cover the essentials for a single-parameter tool. The only gap is undocumented no-match/error behavior.

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 0% and the lone 'query' parameter has no schema description, so the description must compensate — and it does, defining query as a class or title substring matched case-insensitively. Only the expected input format (plain string vs pattern) is left implicit.

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 ('Screenshot a window') and immediately scopes it with the matching rule, which separates it from capture_monitor, capture_region, and capture_active_window. An agent can tell it selects a window by partial match without opening any 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?

No explicit when-to-use guidance and no alternatives named, even though capture_active_window and list_windows are plausible siblings. The matching behavior implies the tool is for partial-name window capture, but the agent must infer that rather than being told.

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 no annotations, the description carries the full behavioral burden. It does disclose two genuinely useful traits: deletion is immediate (irreversible, bulk-wide) and it explicitly does not stop the TTL sweeper, which corrects a likely misconception. However, it says nothing about permissions required, whether in-flight capture operations are affected, or what the returned output reports.

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?

A single sentence with the destructive scope front-loaded, and the parenthetical caveat about the TTL sweeper earns its place by preventing a specific wrong assumption. No wasted words.

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?

The output schema is available so return values need no explanation, and the zero-parameter schema is trivial. For a destructive, unannotated operation the description is nearly sufficient, with the only real gap being the absence of any confirmation or permission caveat before an irreversible bulk delete.

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 there is nothing for the description to disambiguate; baseline 4 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?

"Immediately delete all session captures" names a specific verb (delete) and a specific resource (all session captures), which cleanly separates it from the read-oriented siblings list_captures and capture_window. It stops short of naming a sibling or clarifying its relationship to capture_monitor, so it stays at 4 rather than 5.

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 guidance on when to call this versus the capture_* or list_* tools. The name 'cleanup' implies a housekeeping use case, but the description never states an intended scenario, precondition, or exclusion.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that captures are ephemeral (TTL) and scoped to the current session, but says nothing about ordering, sizing, or whether the listing is exhaustive for the session.

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?

A single short sentence with no wasted words, and the scoping constraint is front-loaded so the agent knows immediately what set of captures is returned.

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 zero-parameter read tool with an output schema present, the description needs only to establish what set is returned, which it does. The remaining gap is minor: no indication of how to remove or act on the listed captures.

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 there is no parameter semantics to explain and the baseline is 4. Nothing in the description misleads about inputs.

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) and resource (captures) plus a meaningful scope qualifier: only captures still alive in the current session within TTL. This separates it from the capture_* siblings that create captures and from cleanup_captures, though it never names those alternatives outright.

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 rather than stated: an agent can infer this is the enumeration step before acting on captures, and the TTL/session qualifier hints results are ephemeral. There is no explicit when-to-use, when-not, or pointer to cleanup_captures for removal.

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?

No annotations are provided, so the description carries the full disclosure burden. 'List' implies a safe, read-only enumeration and the field list hints at a lightweight return, but nothing states side effects, permissions, or ordering. For a zero-parameter, side-effect-free listing tool the omission is minor, so a 3 is fair.

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?

A single front-loaded sentence with no waste; every token (including the field list) earns its place.

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 no-argument listing tool with a full output schema, the definition covers what an agent needs to select and invoke it. Only the absence of explicit when-to-use routing against sibling list tools keeps it from a 5.

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. The parenthetical field list adds a little value about the response shape, though it is redundant with the output 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?

Clear verb+resource ('List available monitors') and it enumerates the returned fields, which cleanly separates it from siblings like list_windows and list_captures. It does not explicitly name a sibling, but the monitors-vs-windows-vs-captures distinction is evident from the resource alone.

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 (discover monitors before calling capture_monitor), but the description never states when to reach for this versus list_windows or list_captures, nor any prerequisites. Adequate minimum-viable guidance with a clear gap.

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 no annotations provided, the description carries the full behavioral burden. 'List' implies a read-only, non-destructive operation, which is useful, but it does not disclose ordering, scope (e.g., minimized windows), permissions, or other traits beyond the output fields already covered by the output schema.

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?

A single, front-loaded sentence with no filler. Every element (verb, resource, returned fields) earns its place.

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?

The description is sufficient for a zero-parameter listing tool with an output schema that already documents return values. It could be slightly more complete by clarifying read-only behavior or usage context, but nothing blocks correct invocation.

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 the schema provides no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description appropriately does not invent parameter 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?

The description states a specific verb ('List') and resource ('open windows'), and names the fields returned ('class, title, and geometry'). This clearly distinguishes it from sibling capture tools and from list_monitors, which targets a different resource.

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 description offers no guidance on when to use this tool versus alternatives such as capture_active_window or capture_window. It merely restates the function without indicating context of use or exclusions.

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