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

With no annotations, the description carries the burden of explaining behavior. It discloses the primary effect—foreground and focus—but does not cover edge cases such as minimized windows, windows on other desktops, failure conditions, or permission requirements. The core behavior is clear, but behavioral detail is minimal.

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, direct sentence with no filler or redundant information. It communicates the action and the object clearly and efficiently.

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 one-parameter tool, the description is mostly sufficient: it states what the tool does and an output schema exists. However, it lacks guidance on how to find a window_id and does not explain behavior for non-obvious cases like minimized or hidden windows.

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 schema already covers the single parameter with a clear description: 'Window identifier' provides 100% coverage. The tool description adds no additional parameter context, so the baseline of 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 uses a specific verb and resource: 'Bring a window to the foreground and focus it.' This clearly states the tool's purpose and semantically distinguishes it from siblings like get_active_window, minimize_window, close_window, and get_window_position.

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 guidance on when to use this tool or when to prefer an alternative. It does not mention how to obtain a valid window_id, whether this works on minimized windows, or how this relates to sibling tools such as get_active_window or set_window_position.

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 behavioral burden. It states the core action and target, which implies a press-and-release click, but it does not mention pointer movement, single-click semantics, or side effects. This is minimally adequate for a simple action but adds little beyond the tool name.

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 front-loaded sentence with no filler. It is appropriately concise, though it sacrifices some useful behavioral context by being so minimal.

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 parameters are fully documented and an output schema exists, so the description doesn't need to explain return values. However, for an agent choosing among many sibling input tools, the absence of contrast or usage guidance leaves a minor completeness 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?

Schema description coverage is 100%, with x/y documented as pixel coordinates and button documented with options and a default. The description adds only the phrase 'screen coordinates' and does not need to compensate for missing schema 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 states a concrete verb ('Click') and a specific target ('specified screen coordinates'). The action and resource are clear, though it doesn't explicitly contrast itself with siblings like computer_double_click or computer_mouse_down/up.

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 guidance is given on when to use this tool versus computer_double_click, computer_move, computer_mouse_down/up, or other input tools. There are no exclusions, prerequisites, or explicit context for choosing this action.

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 present, so the description carries the behavioral disclosure burden. It states that a dictionary is returned, which is useful, but it does not explicitly confirm the operation is read-only, describe behavior on an empty clipboard, or mention any platform-specific differences.

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 extremely concise, front-loads the action, and includes a brief return-value note. Every sentence earns its place with no unnecessary detail.

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?

This is a simple zero-parameter tool with an output schema available, so the description plus schema fully cover what an agent needs to invoke it correctly. There are no missing inputs or complex behaviors to document.

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 and an empty input schema, so there is no parameter semantics burden. The baseline of 4 applies because no parameter explanation is needed.

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 ('Get') and resource ('current clipboard content'), making the tool's function immediately clear. It also distinguishes itself from the sibling computer_clipboard_set by the get/set contrast.

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 provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. However, as a zero-argument getter, the intended use is largely self-evident, though exclusions and context are absent.

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 burden of behavioral disclosure. It fails to mention that setting the clipboard overwrites existing content, any side effects, or requirements. For a mutating tool, this is a significant gap.

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 short sentence, which is concise but under-specified. It doesn't waste words, but it also omits crucial behavioral context, making it more sparse than appropriately concise.

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 tool is simple but mutates system state; the description doesn't disclose that it replaces clipboard content, doesn't specify the environment (e.g., system clipboard), and provides no context about side effects. An output schema exists but its content is unknown, so the description should still cover these gaps.

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 100% and the parameter 'text' is described as 'Text to copy to clipboard'. The description adds no additional semantic value beyond the schema, so the baseline of 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 'Set the clipboard content' uses a clear verb and resource, and the sibling computer_clipboard_get makes the setter's role implicitly distinct. However, it doesn't explicitly name the alternative or elaborate on scope, so it's clear but not fully differentiated.

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 guidance on when to use this tool versus alternatives, no mention of the inverse clipboard_get, and no context about appropriate usage scenarios. The description simply states the action without any selection criteria.

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 must carry the full burden of behavioral disclosure. It only states the action 'close' but does not disclose side effects, such as whether the window is destroyed or just hidden, whether confirmation is required, or if unsaved changes are discarded. This is a significant gap for a destructive action.

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 extremely concise, a single sentence with no fluff. It is front-loaded with the action and resource. While it lacks detail, the brevity is appropriate for such a simple tool; it does not waste 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?

Given that this is a mutation tool (closing a window) with no annotations and no behavioral description, the description is incomplete. An agent may need to know if the operation is reversible, what happens to the window handle, or any prerequisites. The output schema exists but does not compensate for the lack of behavior context. The tool is simple, but the stakes (closing a window) warrant more detail.

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% (window_id is described as 'Window identifier'), so the schema already documents the parameter. The description adds no extra meaning beyond the parameter name, but since coverage is high, the baseline score of 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 clear verb and resource: 'Close a window.' It is direct and unambiguous. However, it does not distinguish itself from sibling tools that also manipulate windows, such as minimize_window or activate_window, though the verb 'close' is distinct enough for basic 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?

No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites (e.g., window must be active), no indication of when closing is appropriate, and no mention of alternatives like minimize or hide. The sibling list includes many window-related tools, but the description gives no routing hints.

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 present, so the description carries the full burden. It honestly describes the action and screen-relative coordinates, but does not disclose whether the pointer is moved first, whether this triggers OS-level side effects, or whether there are any time/order constraints. Adequate for a simple action, but minimal.

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?

One short, front-loaded sentence with no filler. It communicates the essential action and target with maximum efficiency.

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 tool is simple, the input schema is complete, and an output schema exists, so not much is missing. However, the description lacks usage differentiation and behavioral context that would help an agent decide between this and sibling click/move tools. Complete enough to call, but not to select optimally.

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%, with x and y both described as coordinates in pixels. The description adds only the phrase 'screen coordinates,' which is marginal context; the schema already carries the 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?

The description clearly states the action ('Double-click') and the resource ('specified screen coordinates'), making the tool's purpose unambiguous. It does not explicitly contrast with sibling computer_click, though the name and verb make the distinction reasonably clear.

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 guidance is provided about when to use this tool versus computer_click, computer_move, or other pointer tools. There are no exclusions, prerequisites, or alternative recommendations, so the agent must infer usage 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the abstract action and does not mention that a drag typically involves pressing a button, moving the cursor, and releasing, nor any side effects or reversibility. This is a notable transparency gap for an input-mutation 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 description is a single, front-loaded sentence with no filler or repetition. It is appropriately sized for the tool's simplicity, though slightly sparse in behavioral context.

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 the tool has no annotations, multiple parameters, and many sibling input tools, the description is incomplete: it does not explain the press-move-release behavior, when to use drag over alternatives, or what result to expect. The output schema exists, so return values need not be described, but behavioral and selection context is still 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 baseline is 3; the schema already documents all six parameters including defaults. The description adds only the general notion that start and end values define a drag path, without adding extra meaning for button or duration. This is adequate but not additive.

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 uses a specific verb ('drag') and a precise operation ('from start coordinates to end coordinates'), making the core action clear. It does not explicitly distinguish drag from sibling tools like computer_move or computer_mouse_down/up, but the term 'drag' is a recognizable distinct action.

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 implies the tool is for drag interactions, but it provides no explicit guidance on when to choose it over alternatives such as computer_move, computer_mouse_down, or computer_mouse_up. An agent is left to infer the boundary between dragging and composing a move/click sequence manually.

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 of behavioral disclosure. It only states the action without revealing search semantics (e.g., recursive vs. top-level, first match vs. all matches), side effects (none expected but not stated), or failure behavior. This is a significant gap for a tool that likely returns element locations.

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 filler. It is appropriately short and immediately states the action and resource, though this conciseness comes at the cost of missing behavioral context.

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 the tool has three optional search parameters, an output schema, and numerous interaction siblings, the description should at least hint at the returned data or how it fits into a workflow (e.g., feeding coordinates to click). It doesn't, leaving an agent to infer the tool's role and return value.

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 100%, and each parameter (role, title, value) has a clear description, so the baseline is 3. The tool description adds no additional semantic value beyond what the schema already provides, but the schema fully documents the parameters.

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 uses a specific verb ('Find') and a clear resource ('UI element in the accessibility tree'), which distinguishes it from sibling tools like computer_get_accessibility_tree (which retrieves the whole tree) and interaction tools (which act on elements). An agent can immediately understand what the tool does.

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 provides no information about when to use this tool versus computer_get_accessibility_tree or the click/type tools. An agent cannot determine whether to call find_element first to get coordinates or to parse the tree directly, and no alternatives or exclusions are mentioned.

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 behavioral burden. It discloses that the tool returns a dictionary of accessibility tree information, which implies a read-only inspection operation. It does not mention edge cases such as what happens if no window is focused or whether the result can be empty.

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 compact and well-organized: a one-sentence purpose, a brief justification of usefulness, and a clear returns clause. There is no redundant or wasted text.

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 parameterless getter with an output schema present, the description covers the tool's purpose, general content, and return type. It could be more complete by naming sibling alternatives and noting behavioral edge cases, but nothing else is required to invoke 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?

The tool has zero parametersressing, so there is no parameter semantics for the description to add. The input schema is already complete, and 'current window' is contextual rather than a parameter.

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 states the action (get) and the resource (the accessibility tree of the current window), and explains what the tree contains. It is distinct in resource type from the sibling tools, though it does not explicitly contrast itself with similar inspection tools like computer_find_element or computer_screenshot.

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 implies when the tool should be used by mentioning that it is useful for finding clickable elements and understanding UI structure. However, it does not provide explicit guidance on when to prefer this tool over alternatives or when not to use it.

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?

The word 'Get' and the documented dictionary return imply a read-only, non-mutating operation, and the return shape is disclosed. With no annotations present, the description carries the burden, but it omits any edge-case behavior such as what happens if no active window exists or whether permissions are required.

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 concise sentences with no filler. The core purpose is front-loaded, and the return type is stated directly.

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 getter with an output schema, the description is sufficient: it states the operation and the return key. It could add a note about the absence of an active window or environment requirements, but these are not critical for basic 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 empty schema fully covers parameter semantics. The baseline for 0-parameter tools is 4, and no additional parameter documentation is needed.

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 states the operation ('Get the currently active window ID') and the exact return contract (dictionary with 'window_id' key). It does not explicitly contrast with sibling tools like computer_get_window_name, but the return key makes its distinct purpose clear.

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: use this when you need the active window's ID. However, the description provides no explicit when/when-not guidance or mention of alternatives among the many sibling computer_* tools.

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 of behavioral disclosure. It only restates the basic operation and does not mention whether hidden/minimized windows are included, ordering, failure behavior when the app is not running, or any 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?

The description is a single compact sentence with no wasted words. It front-loads the core action and resource while remaining immediately scannable.

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 tool is simple, has a single documented parameter, and an output schema exists, so return-value structure need not be described. However, the lack of usage guidance and behavioral nuance leaves some contextual gaps for an agent deciding when and how to use it.

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%, with the 'app' parameter already documented as 'Application name or bundle identifier'. The tool description does not add parameter-level detail, so the schema handles the parameter semantics and the baseline of 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 ('Get') and resource ('all windows belonging to an application'), making the tool's scope clear. It distinguishes itself from siblings like get_active_window by emphasizing 'all windows' rather than a single active window.

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 guidance is given on when to use this tool versus alternatives such as get_active_window, get_window_name, or get_window_size. The intended usage is only implied by the tool name and one-line description, with no explicit context or exclusions.

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 burden of behavioral disclosure. 'Get' clearly indicates a read-only operation and the return shape is specified, but the description does not explicitly state that there are no side effects or mention the coordinate system. This is adequate but not rich.

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 two concise sentences with the core purpose front-loaded. The return format is stated briefly and no unnecessary words are used.

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-only tool with an output schema, the description is complete enough for an agent to invoke it correctly. It states what the tool does and what it returns; no critical operational context 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?

The tool has zero parameters, so the description has no parameter documentation burden. A baseline of 4 is appropriate since there is nothing additional the description needs to clarify 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?

The description names a specific verb ('Get') and resource ('current cursor position'), making the tool's function immediately identifiable. It is naturally distinct from siblings like computer_get_screen_size and computer_get_active_window, since no other tool claims cursor position.

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 guidance about when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The tool's purpose is self-evident from its name, but the description itself does not provide any usage context.

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 behavioral burden. It discloses that the tool 'Returns Dictionary with desktop environment details,' which is useful for a read-only getter. However, it does not describe error behavior, possible null/empty return, or exactly what the dictionary contains, though an output schema exists to help.

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 two short sentences with the core purpose front-loaded and no filler. The return note is concise and earns its place by clarifying the expected output shape.

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-parameter read-only getter with an output schema present, the description is mostly sufficient. It does not need to explain return values in detail because the output schema exists, but the phrase 'desktop environment details' is slightly vague and leaves the exact contents to inference.

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, and the input schema has no properties, so schema coverage is complete. The description correctly adds no parameter details because none are needed. This meets the baseline for a parameterless tool.

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 clear verb+resource: 'Get information about the current desktop environment' and notes the return type. However, it does not differentiate this from the similar sibling 'computer_get_desktop_state', leaving some ambiguity about which tool reports the environment versus the state.

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 guidance on when to use this tool rather than a sibling such as computer_get_desktop_state, computer_get_screen_size, or computer_get_active_window. It only restates the purpose, so an agent receives no context for tool selection.

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 full behavioral burden. It discloses the important backend restriction and an escalation rule, but does not explain side effects such as whether a screenshot file is written, what the capture actually returns, or what 'whole desktop' means operationally. Partial transparency rather than full.

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 tight sentences with the primary action front-loaded and the availability caveat placed immediately after. Every clause carries meaning and there is 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?

The tool is simple and an output schema exists, so return values do not need detailed description. However, the parameter's semantics are entirely unexplained and the 'window-focused ladder' allusion is undefined, leaving gaps that an agent would need to resolve before confident use.

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 single parameter screenshot_out_file has zero schema coverage, and the description never mentions it. The agent cannot infer whether it is an output path, whether null selects a default behavior, or what file format is produced. The schema provides no help, so the description fails to compensate.

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 action ('Capture the whole desktop') and a resource ('whole desktop') tied to an active Cua Driver session. This is distinct from window-focused capture tools, though it does not explicitly name a sibling tool like computer_screenshot.

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 provides explicit when-to-use constraints: it is only available when CUA_BACKEND=cua-driver, and in an auto session it should be used only after the window-focused ladder is exhausted. It lacks explicit naming of alternative tools or direct 'when not to use' phrasing, but the conditions are concrete and actionable.

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 must carry the behavioral burden. It does imply a read-only retrieval operation via the verb 'Get' and describes the returned dictionary, but it does not disclose whether 'screen' means primary monitor, current display, or combined desktop, nor any potential error behavior. For a simple getter, this is adequate but not thorough.

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 barely two sentences long fashion, front-loads the core purpose, and includes the essential return information without any filler. Every word 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 zero-parameter getter with an output schema, the description is nearly complete. The only meaningful gap is the lack of specification about which screen is being queried in multi-monitor setups, and no mention of when to use alternatives. Still, an agent can confidently invoke it and interpret the result.

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 input schema has zero parametersores, so there is nothing for the description to document. Baseline for a 0-parameter tool is 4, and the description appropriately notes the action requires no input without attempting to 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 uses a specific verb ('Get') and resource ('screen dimensions'), clearly distinguishing this from siblings like computer_get_window_size and computer_get_cursor_position. It even specifies the return shape ('width' and 'height' keys in pixels), leaving no ambiguity about what this tool does.

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 prefer this tool over alternatives. Given siblings like computer_get_window_size and computer_get_desktop_state exist, it would help to explicitly state that this is for the full screen rather than a window or active display, and that no arguments are needed.

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 present, so the description must carry the transparency burden. It states the core behavior (retrieve a window title) but does not mention behavior for invalid window_id, whether the title is a plain string, or any platform-specific quirks. For a simple read-only getter this is acceptable but not rich; a bit more detail would help.

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?

Single concise sentence, no filler, front-loaded with the verb. Every word 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 tool is simple and the output schema exists, so return-value details are not required. However, there is no mention of alternatives or edge-case behavior, which leaves the description only minimally complete. For a one-parameter getter it is adequate, but it could tie to sibling tools.

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 100% and the sole parameter window_id is described as 'Window identifier.' The description adds no further parameter semantics beyond restating 'window.' Baseline 3 applies because the schema already does the work.

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 ('Get') and resource ('title/name of a window'). It is clearly distinct from sibling tools like get_window_size or get_window_position; the agent knows exactly what data is returned. The only slight gap is not explicitly saying the window is identified by window_id, but that is in the 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?

Provides no guidance on when to prefer this over computer_get_active_window or computer_get_app_windows, nor any exclusions. The 'when to use' must be inferred entirely from the tool name and the sibling context. This is below the minimum for helping an agent choose correctly among similar getter tools.

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?

The verb 'Get' implies a read-only operation, which is a useful behavioral signal, and the description does not contradict any annotations. However, without annotations, the description carries the full burden and does not disclose coordinate space, whether the window must be visible or active, or failure 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 description is one short, front-loaded sentence with no filler. It is concise, though it is terse enough that it omits details that could aid the agent in selecting or invoking the tool.

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 one-parameter getter with an output schema, the description is minimally adequate. It correctly conveys the core operation, but it lacks contextual details like coordinate system conventions and does not position the tool relative to its 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?

The input schema already documents the single parameter, window_id, as 'Window identifier' with 100% coverage. The description adds no extra meaning about how the identifier should be obtained or formatted, so a baseline score of 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 uses a specific verb ('Get') and resource ('position of a window'), clearly stating what the tool does. It is distinguishable from siblings like get_window_size and set_window_position, though it does not explicitly contrast itself with 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?

The description provides no guidance about when to use this tool instead of alternatives such as get_active_window or set_window_position. There are no explicit contexts, prerequisites, or exclusions, so the agent must infer usage entirely from the tool name.

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 must disclose behavioral traits. It only says 'Get the size of a window' without noting that it requires a window ID, what units the size is in (pixels), whether the window must be currently open, or any potential errors. This is minimal and leaves the agent guessing about prerequisites and edge cases.

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, concise sentence with no extraneous words. It is appropriately brief for a simple getter, and the information is front-loaded. No waste.

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 an output schema, which likely describes the size format (width/height), so the return value is covered by that. However, the description does not mention any prerequisites (e.g., the window must exist), error conditions, or the fact that the window ID is required. Given the simplicity and the output schema, this is still incomplete because the agent has no guidance on what happens if the window is invalid or how to obtain the window_id.

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 schema covers 100% of the parameter with a description ('Window identifier'), so the description adds no new meaning. The description does not clarify what constitutes a valid window_id (e.g., numeric ID vs. name), so while the baseline is 3, the lack of additional detail keeps it there.

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 states that the tool gets the size of a window, which aligns with the name and identifies the resource and action. It is distinct from sibling tools like set_window_size or get_window_position, though it could explicitly mention that it returns width and height, which is implied.

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 does not provide any guidance on when to use this tool versus alternatives. However, the purpose is self-evident and the sibling context suggests it is a basic read operation for window size. Missing explicit context about when to prefer it over get_window_position or set_window_size, but not misleading.

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 burden of behavioral disclosure. It clearly states the core behavior—pressing a key combination—but gives no additional context such as whether keys are pressed briefly, whether focus is required, or what the return value means.

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, front-loaded sentence with no filler. It efficiently communicates the action, and the parenthetical 'hotkey' reinforces the tool's purpose.

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 one-parameter tool with a rich parameter schema and an output schema, the description is nearly complete for invocation. The main gap is the lack of explicit guidance distinguishing it from sibling keyboard tools, but the word 'combination' partially covers this.

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 the 'keys' parameter with useful examples. The description itself adds little beyond the word 'hotkey,' and does not need to compensate for missing schema 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 states a specific action ('Press') and a specific resource ('a key combination (hotkey)'). The word 'combination' hints at how this differs from sibling tools like computer_press_key, though it does not explicitly name 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?

No guidance is given on when to use this tool versus alternatives such as computer_press_key, computer_key_down, computer_key_up, or computer_type. The description implies simultaneous key combinations but provides no explicit context or exclusions.

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 of behavioral disclosure. 'Press and hold' implies a stateful action, but the description does not explain how long the key stays held, how to release it, or what side effects may occur.

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, front-loaded sentence with no filler words. It is efficiently concise, though it omits important usage context that belongs elsewhere in the definition.

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 tool this is minimally viable: it names the action and the relevant parameter. However, it leaves a clear gap by not stating that the key remains held until a release action like computer_key_up is invoked, which is important for correct agent 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?

The schema already fully documents the only parameter, 'key', as 'The key to hold down', so the description adds little beyond the schema. With 100% schema description coverage, the baseline of 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 action ('Press and hold') on a specific resource ('a key'), so the tool's core purpose is clear. It distinguishes itself from siblings like key_up and press_key through the word 'hold', but it does not explicitly contrast itself with those alternatives.

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 provides no guidance on when to use this tool versus siblings such as computer_press_key, computer_key_up, or computer_hotkey. It also does not mention that key_down should typically be paired with a later key_up call.

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 disclosure burden. It does reveal a meaningful behavioral condition: the key must already be held. However, it does not disclose what happens if no key is held (no-op vs. error) or whether any status/result is returned.

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 words with zero filler: it identifies the action and the target resource immediately. Every word 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 one-parameter, low-complexity tool with an output schema, this description is largely complete. The only notable gap is the lack of an explicit link to computer_key_down as the paired operation that creates the held state.

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 input schema already fully documents the single 'key' parameter with 100% coverage. The description adds no additional parameter-level meaning, so the schema adequately handles this dimension.

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 precise verb and resource: release a key that is currently held. This clearly distinguishes it from sibling tools like computer_key_down (press/hold) and computer_press_key (tap), as well as from mouse_up.

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 guidance is given about when to use this tool versus alternatives. The phrase 'held key' implies pairing with computer_key_down, but the description does not state this prerequisite or mention that single taps should use press_key instead.

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 of behavioral disclosure. It only says 'Launch an application' and does not reveal whether the call waits for the app to open, returns a process handle, fails if the app is already running, or requires a desktop session. This is a significant gap for a tool that starts external programs.

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 short sentence with no filler or redundancy. It is appropriately sized for a low-complexity tool and front-loads the core action clearly.

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 two parameters already fully covered by the schema and a simple launch action, the description is minimally adequate. However, it does not explain launch semantics or how it differs from the many sibling tools, particularly computer_open and computer_activate_window, so an agent selecting among 35 siblings receives only the bare minimum context.

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 input schema documents both parameters thoroughly: 'app' is 'Application name or path' and 'args' is 'Optional list of arguments to pass to the application'. Since schema description coverage is 100%, the description does not need to add parameter-level detail, giving the baseline score of 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?

The description states a clear action ('Launch') and a clear target ('an application'), so an agent can tell that this tool starts an app. However, it is almost a restatement of the tool name and does not differentiate this from sibling tools like computer_open, which could also launch an application in some contexts.

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 guidance on when to use this tool versus computer_open, computer_activate_window, or computer_get_app_windows. It mentions no alternatives, prerequisites, or exclusions, so the agent is left to infer usage purely from sibling names.

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 of behavioral disclosure. It only says 'Maximize a window' and omits side effects, preconditions, idempotence, and whether other windows are affected. Because this is a mutating operation, the lack of behavioral context is a meaningful gap.

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 short sentence with no filler or redundancy. It is easy to parse and front-loaded, though it is so terse that it borders on under-specification rather than being a fully helpful description.

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 the tool's low complexity, a single required parameter, and an existing output schema, the description is partially sufficient for invoking it correctly. However, with no annotations and no mention of preconditions or behavioral effects, the information is not fully complete on its own.

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 input schema fully describes window_id as 'Window identifier' with 100% coverage, so the description does not need to add much. However, the description adds no additional meaning or format guidance for the parameter, landing at the baseline 3 for high schema coverage.

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 states the action and resource: maximize a window. The tool name and one-sentence description leave no ambiguity about what it does. However, it does not explicitly distinguish itself from related siblings like minimize_window, activate_window, or set_window_size, 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 guidance about when to use this tool versus alternatives. It does not mention when maximize is preferred over set_window_size, nor does it state whether the window must already be open or whether the operation also activates/raises the window. The usage context is left entirely 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the action and does not mention side effects, whether minimizing is idempotent, whether focus changes, or what happens if the window_id is invalid.

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, front-loaded sentence with no filler or redundancy. It is appropriately brief for a one-parameter tool, though it does not use the available space to add helpful context.

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 the low complexity, documented parameter, and presence of an output schema, the description plus schema is minimally callable. However, it lacks guidance on how to find a valid window_id or what behavior to expect after the call, leaving clear gaps.

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 schema already describes the sole window_id parameter at 100% coverage as 'Window identifier'. The description adds no additional meaning about how to obtain or use the identifier, so the baseline score of 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 clear verb ('Minimize') and a specific resource ('a window'), so an agent can understand the intended action immediately. It does not explicitly contrast with sibling tools like maximize_window or close_window, but the action itself is unambiguous.

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 guidance about when to use this tool instead of alternatives such as activate_window, maximize_window, or close_window. No prerequisites, workflow context, or exclusion conditions are 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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose the key stateful behavior—the button is pressed and held—which is useful. However, it does not mention that the press persists until a corresponding mouse_up, or any side effects such as how this interacts with dragging.

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, clear seven-word sentence with zero filler. Every word contributes to communicating the operation.

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 stateful input operation with a fully documented schema and an output schema present, the description is nearly complete. It tells the agent the button is pressed and held, and the schema covers optional coordinates and button choice. A minor gap is the lack of explicit guidance about pairing with computer_mouse_up for a full click or drag gesture.

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 parameters (x, y, button) are already fully documented. The description adds no new semantic information beyond referring to 'a mouse button,' which matches the 'button' parameter. The baseline of 3 is appropriate because the schema does the heavy lifting.

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 uses a specific verb and resource combination: 'Press and hold a mouse button.' This clearly distinguishes the operation from siblings like computer_click, computer_double_click, and computer_mouse_up by emphasizing the sustained press rather than a tap or release.

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 guidance on when to use this tool versus alternatives such as computer_click or computer_drag, and no mention of pairing it with computer_mouse_up. The intended usage is only implied by the tool name and the phrase 'press and hold,' not explicitly stated.

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 bears full responsibility for behavioral disclosure. It only states the basic action and omits important behavior such as whether specifying x/y first moves the cursor, whether a release is a no-op if no button is held, and what the default button behavior is beyond what the schema already states.

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 concise sentence with no fluff or redundancy. It is appropriately brief, though it sacrifices useful context for brevity.

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 low-level mouse action with optional coordinates and an output schema, the description is too sparse. An agent cannot tell whether coordinates cause a cursor move before release, how the tool behaves relative to mouse-down state, or which button is acted upon by default without opening the schema.

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 all three parameters (x, y, button) are already documented. The description adds no additional parameter meaning, which is acceptable under the baseline for fully covered schemas.

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 uses a specific verb ('release') and resource ('mouse button'), making the core action clear and disambiguating the tool from a literal 'move mouse up' interpretation. However, it does not explicitly differentiate from related siblings like computer_mouse_down or computer_click beyond the verb itself.

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 guidance on when to use this tool versus alternatives. It does not mention that it pairs with computer_mouse_down, nor does it explain when a click, double-click, or drag would be more appropriate.

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 must carry the behavioral burden. It states the core action—moving the cursor to screen coordinates—but does not clarify that it does not click or drag, how the movement is performed, or whether hover events are triggered. The behavior is not misleading, but extra transparency is limited.

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, front-loaded sentence with no wasted words. Every part contributes to understanding the tool's purpose and target.

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 two-parameter tool with a full schema and an output schema present, the description plus structured data is nearly sufficient. The only minor gaps are the lack of explicit no-click/drag clarification and coordinate origin, but these are not critical for basic 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 schema already fully describes both parameters as X and Y coordinates in pixels, so the description adds no additional semantic value beyond what is structured. This matches the baseline for 100% schema description coverage.

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 uses a specific verb ('Move') and resource ('cursor') with a precise target ('specified screen coordinates'). This clearly distinguishes it from sibling tools like computer_click, computer_drag, and computer_get_cursor_position, so an agent can tell what it does without needing to open the 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?

There is no guidance on when to use this tool versus alternatives such as computer_click or computer_drag. It does not state prerequisites, whether it should be used before a click, or when a different cursor-related tool would be more appropriate.

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 bears full responsibility for behavioral disclosure. It mentions 'with the default application', which is a behavioral detail, but it does not describe error handling, whether the call blocks, what side effects occur (e.g., opening a new window), or the nature of the response. For a tool that could fail if the target is invalid, this is a notable gap.

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, concise sentence that states the action and resource immediately. There is no filler, and it is front-loaded. It is appropriately sized for a tool with one parameter.

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 tool is simple (one parameter) and has an output schema, so return values are already documented. The description covers the core behavior and the target type. It does not explicitly differentiate from computer_launch_app, but the purpose clarity largely compensates. It is adequately complete for an agent to understand when to use it, though it could mention edge cases (e.g., invalid path).

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 schema already describes 'target' as 'File path or URL to open', and the description repeats this without adding new meaning (e.g., path format, URL schemes, or examples). Since schema coverage is 100%, the description adds no extra semantic value beyond the schema, so a baseline of 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 clearly states the action ('Open') and the resource ('a file or URL') with the qualifier 'with the default application'. This is specific and distinct from siblings like computer_launch_app (which would launch an app) and computer_click (which interacts with UI). It leaves no ambiguity about the tool's function.

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 does not explicitly mention when to use this tool versus alternatives. There is no reference to computer_launch_app or any other sibling, and no exclusionary guidance. The intended usage is implied by the purpose, but it does not proactively steer an agent away from other similar tools, leaving some inference required.

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 must carry the behavioral burden, and it states only the core action: a single key press. It does not explicitly say whether the key is automatically released, whether an active window/focus is required, or what other side effects may occur, though these are less critical for such a simple action.

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 four words and front-loaded with the verb and object. There is no filler, repetition, or unnecessary detail.

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 tool with a fully documented schema and an output schema, the description is largely enough to invoke correctly. The main missing piece is routing to the correct sibling, which is a guidance gap rather than a completeness 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?

The schema already documents the key parameter with examples (100% coverage), so the description adds little parameter-level value. The word 'single' is the only added semantic, clarifying that the parameter should not be a combination.

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 specifies a clear verb ('press') and resource ('key'), and the qualifier 'single' helps separate it from hotkey or type operations. It does not, however, differentiate it from computer_key_down or computer_key_up, which also act on a single key.

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 guidance about when to choose press_key over the sibling tools such as key_down, key_up, hotkey, or type. An agent is left to infer the right conditions 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It states the tool returns the current screen as an image and implies a read-only observation, but it does not explicitly mention side effects, permissions, or output format limitations. For a simple screenshot tool this is acceptable but not thorough.

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 short and front-loaded with the primary action in the first sentence. The second sentence adds the output type, and the third gives usage guidance. Minor redundancy exists between the first and second sentences, but overall it is efficient.

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 essential context: what it does, what it returns, and when to call it. There is no output schema, but 'as an image' is sufficient. Gaps such as image format or resolution are not critical for basic 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 is fully covered and the description needs no parameter-level detail. The baseline of 4 applies because there is nothing missing for an agent to understand how to invoke it.

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 action and resource: 'Capture a screenshot of the current screen' and clarifies it returns an image. It is unambiguous about what the tool does, though it does not explicitly distinguish itself from sibling tools such as computer_get_desktop_state.

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 an explicit usage instruction: 'Always call this first to see what's on screen before performing any actions.' This provides clear context for when to use it, but it does not mention alternatives or when not to use it.

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 of explaining behavior. It only states the action and does not disclose whether the cursor moves to x/y, what happens when scroll_x/scroll_y are both zero, or any side effects of the scroll operation.

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, short sentence with no filler or repetition. It is appropriately front-loaded, though it is so terse that it sacrifices useful behavioral and usage context.

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 not complete enough for a tool with four parameters and no annotations. It omits how x/y and scroll_x/scroll_y interact, whether the pointer is moved to the position, and how this differs from sibling mouse tools. The output schema is present, so return values do not need explanation, but behavioral context is still 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?

The schema description coverage is 100%, and each parameter already has a clear description (X coordinate, Y coordinate, horizontal scroll amount, vertical scroll amount). The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 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 uses a clear verb ('scroll') and a target ('the specified position'), and the action is distinct from sibling tools like move, click, or drag. However, it does not differentiate from siblings or clarify what 'position' means beyond the 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?

There is no guidance on when to use this tool versus alternatives such as computer_move or computer_mouse_down. No context, prerequisites, or exclusion criteria are provided, leaving the agent to infer the appropriate scenario.

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 of behavioral disclosure. It does not state whether the window is moved instantly, whether coordinates are relative to the screen or workspace, whether the window is activated, or what happens if the window_id is invalid. For a mutating tool this is a meaningful gap.

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 efficient sentence that states the action clearly and front-loads the purpose. There is no filler or unnecessary repetition, and it earns its place as a concise definition.

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?

This is a simple three-parameter tool with an output schema, so extensive documentation is not required. However, the description omits important operational details such as the coordinate system/origin and the effect on window activation, which an agent may need to call it correctly in a GUI automation context.

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 schema has 100% description coverage, so all three parameters are documented, but the descriptions are thin ('New X position', 'New Y position', 'Window identifier'). The tool description adds little beyond implying that x and y define the new position, which matches the baseline for full schema coverage.

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 uses a specific verb and resource ('Set the position of a window') that clearly distinguishes it from sibling tools like set_window_size and get_window_position. It is not a tautology and conveys the core action, though it does not explicitly mention coordinates or screen placement.

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 guidance about when to use this tool instead of related tools such as get_window_position, set_window_size, or activate_window. The intended usage is only implied by the name and description, with no exclusions or alternatives 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Set the size of a window' is minimal and does not disclose whether the operation is reversible, what happens if the window is invalid, whether the window moves or resizes in place, or any side effects. This is a significant gap for a mutation tool with zero annotation coverage.

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 short sentence with no wasted words, which is efficient. However, it is under-specified and does not provide enough context for a mutation tool. It is concise but not substantively sufficient, so it earns a middle score.

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 that there are no annotations and the tool is a mutation, the description is incomplete. It does not mention behavior like whether the window must be active, how errors are handled, or what the output schema contains (though an output schema exists, the description still lacks operational context). For a simple tool this might be acceptable, but the absence of any behavioral notes makes it inadequate for an agent to fully anticipate side effects.

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 input schema has 100% coverage with descriptions for each parameter, so the schema already documents the three parameters. The description adds no additional nuance beyond what the schema provides, such as constraints or relationships. Baseline 3 is appropriate when the schema carries the semantic load.

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 clear verb ('Set') and resource ('size of a window'), which is unambiguous. However, it does not explicitly distinguish from sibling tools like computer_set_window_position, though the resource difference is implicit. The purpose is clear but lacks explicit sibling 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?

No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this only changes dimensions and not position, nor does it indicate any prerequisites such as the window needing to exist or be active. The description gives no context for selection among siblings.

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 of behavioral disclosure. It explains the core action but omits important behavior such as whether the tool simulates keystrokes, requires an active text field/cursor, or how it handles newlines and special characters. The phrase 'current cursor position' hints at a prerequisite but does not make it explicit.

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 word contributes to meaning, and the simple structure matches the tool's low parameter count.

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 core operation and parameter are covered, and an output schema exists, but the description is missing actionable context about prerequisites (focused text field) and how this tool relates to the input-focused siblings. For a low-complexity tool this is adequate but not comprehensive.

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% and the single 'text' parameter already has the description 'The text to type' in the schema. The tool description adds no additional parameter semantics, so the baseline score of 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 uses a specific verb ('Type') and a precise resource ('text at the current cursor position'), which clearly separates it from sibling tools like press_key, hotkey, or clipboard_set. The intent is unambiguous even before looking at the parameter 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?

The description states what the tool does but provides no guidance about when to prefer it over alternatives or when not to use it. It does not mention that it is for free-text entry rather than single keys or key combinations, nor does it instruct the agent to ensure a text field is focused first.

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