codex-computer-use-linux

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

Beyond the annotations (all false, providing little safety context), the description discloses that the pointer first moves to absolute screenshot coordinates and defaults to a single click. This adds meaningful behavioral context, though details like waiting behavior or output are omitted.

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 that front-load the primary action and immediately follow with a key usage detail. Every word adds value.

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 action and coordinate system are covered, but the description does not mention button options, valid count range, or timing behavior. With five parameters and no parameter descriptions, more context would help, though the simplicity of the tool makes it somewhat adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies that x/y are absolute screenshot coordinates and hints at count via the double-click note, but it does not explain count, button, or interval_ms parameters beyond their defaults.

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 tool's action: 'Move to absolute screenshot coordinates and click a mouse button.' The verb 'click' and resource 'mouse button' are specific, and the coordinate context distinguishes it from siblings like move_pointer and drag_pointer.

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 on when to use this tool versus alternatives. The only usage note is about using one click unless a double-click is clearly needed, which addresses count behavior rather than 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by explicitly stating 'This does not capture the screen or send input,' reinforcing no side effects, and mentioning 'safety warnings' as part of the output, which provides behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences. The first sentence front-loads the primary action and scope, while the second clarifies limitations. No extraneous words; every sentence 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 simple tool with no parameters and annotations covering safety, the description effectively covers all needed context: the purpose, what it detects, usage timing, and explicit non-actions. The output schema handles return value details, so the description is complete for an inspection tool.

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 schema coverage is trivially complete (100%). Description does not need to explain parameters, but it adds relevant context about what the tool detects and returns, satisfying the baseline of 4 for zero-parameter tools.

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 tool's purpose with specific verbs ('detect') and resources (Wayland/X11, screenshot/input backends, active window, safety warnings). It explicitly distinguishes itself from sibling tools by stating what it does not do, making the purpose 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?

'Call first' is an explicit usage instruction indicating this tool should be used before others to detect environment capabilities. The description also clarifies it does not capture the screen or send input, guiding users away from using it for those actions and toward sibling 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?

Annotations already indicate the tool is mutating (readOnlyHint=false) and not idempotent. The description adds the key dependency on the latest screenshot, which is valuable. It does not describe the full drag sequence (press-move-release) or potential side effects, so some behavioral detail remains undisclosed beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no unnecessary words. It front-loads the core action and packs the essential constraint (screenshot dependency) into a concise statement. Every word contributes to understanding.

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 has five parameters and a dependency on prior screenshots, both of which are addressed. The description doesn't explain return values, but an output schema exists. Given the simplicity of the action, the description provides sufficient context for an agent to understand usage, though it could briefly mention the press-move-release behavior to be fully complete.

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 clearly defines parameter names, types, and bounds, but the description adds crucial meaning by specifying that coordinates are absolute and come from the latest screenshot. It does not elaborate on the button parameter, though the schema provides an enum and default. Since schema coverage is 0%, the description partially compensates but not fully.

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 the specific verb 'drag' and clearly identifies the resource (mouse button) and the action's scope (between two absolute coordinates from the latest screenshot). This distinguishes it from sibling tools like move_pointer (which moves without holding a button) and click (single click).

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 that the tool operates on coordinates from the latest screenshot, indicating a dependency on a prior screenshot. However, it doesn't explicitly state when to use this over alternatives like move_pointer or click, nor does it mention exclusions. Usage context is implied but not fully explicit.

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?

Annotations already cover idempotency and destructiveness. The description adds the key context that coordinates are relative to the latest screenshot, which is useful. However, it does not describe potential side effects (e.g., pointer motion animation) or failure modes, so it only partially goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that wastes no words. It explains the core action, coordinate source, and scope immediately, making it highly scannable and effective.

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 annotations and an output schema, the description provides sufficient context: it names the action, the coordinate reference, and implies the prerequisite of a screenshot. It could mention the relationship to 'take_screenshot' or 'click' for fuller contextual integration, but overall it is complete enough for an agent to invoke 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?

Schema only defines x and y as integers. The description enriches these by stating they are 'absolute coordinates from the latest screenshot', clarifying their meaning and coordinate system. Since schema coverage is 0%, this is a significant contribution, though it could be more explicit about whether coordinates are pixel-based or relative to the screenshot's resolution.

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 ('move'), the target resource ('pointer'), and the specific coordinate basis ('absolute coordinates from the latest screenshot'). This distinguishes it from sibling tools like 'click' or 'drag_pointer' by specifying that it only moves, and the coordinate reference is unique.

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 usage context: it should be used after taking a screenshot, since coordinates are derived from that screenshot. This provides clear context but does not explicitly mention alternatives or when not to use the tool, so it stops short of a 5.

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

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

Annotations indicate the tool is not read-only, so a side effect is expected. The description adds that the key must be allow-listed and that the action targets the focused Linux app, which is useful context, but it does not elaborate on potential side effects or restrictions beyond that.

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, well-structured sentence that conveys the essential purpose, scope, and modifier options without 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 tool with only one required parameter, the description is mostly adequate, but the undefined 'allow-listed' key set is a notable gap. It does not specify which keys are accepted, which could lead to failed invocations. However, the output schema exists, so return values are not the responsibility of the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions the key and modifier options, but does not explain the interval_ms parameter, and the 'allow-listed key' set is left undefined. Thus, parameter semantics are only partially addressed.

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 ('Press') and resource ('key'), clearly stating the action is a single key press with optional modifiers in the focused Linux app. This distinguishes it from related tools like type_text and click.

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 clearly communicates when to use this tool: pressing a key with modifiers in the focused Linux app. It implies a distinction from text typing or mouse actions, though it does not explicitly name alternative tools or exclusion 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?

The description adds the crucial sign convention ('Positive scrolls up and negative scrolls down') and clarifies it is for X11 by contrasting with Wayland. Annotations provide no safety hints (all false), so this context carries the burden, and it does so adequately, though it doesn't disclose the exact mechanics of the scroll event.

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 sentences, front-loaded with the action, then sign convention, then the alternative. Every sentence earns its place with zero fluff.

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 single-parameter scroll tool with an output schema present, the description covers all necessary aspects: purpose, parameter semantics, alternative usage, and platform note. No significant gaps remain.

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 no description for 'steps' (0% coverage), but the description explains the direction meaning of positive/negative values. It does not specify what a 'step' exactly corresponds to (e.g., lines or notches), but the bounded range implies discrete increments, so the meaning is sufficiently clarified.

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 'Scroll vertically by a small number of steps' with a specific verb and resource (X11 desktop), and it distinguishes from siblings by explicitly naming press_key as the Wayland alternative. This is a clear, non-tautological purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'On Wayland use press_key with PAGEUP or PAGEDOWN instead.' This tells the agent exactly when to avoid this tool and what to use instead, leaving no ambiguity about platform applicability.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds context beyond annotations by specifying it captures the Linux desktop as PNG image content, and that it reflects visible state. This is useful, though it could mention potential caveats like screen resolution or multi-monitor handling, but that is minor given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states purpose, the second gives usage guidance. It is front-loaded, efficient, and every sentence earns its place with no redundancy or fluff.

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, zero-parameter tool with strong annotations, the description is complete. It covers what it does (capture desktop screenshot), the output format (PNG), the platform (Linux), and when to use it (before coordinate selection and after state changes). No critical information 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 schema coverage is 100% and there is nothing to explain. The baseline for zero parameters is 4, and the description adds clarity about the output format (PNG image content), which is relevant context even though not 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 states a specific verb ('Capture') and resource ('current Linux desktop'), with a clear output format ('PNG image content'). It clearly distinguishes itself from sibling tools like click or type_text, which are input actions rather than observation.

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 usage guidance: 'Use before choosing coordinates and again after every action that changes visible state.' This tells the agent exactly when to invoke this tool relative to other actions, which is highly actionable and context-rich.

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?

Annotations are sparse (all hints false) and do not disclose safety or side effects. The description adds context about 'plain text' and 'focused control', implying a non-interpretive typing action. It does not explain behaviors such as whether existing text is replaced, what happens if no control is focused, or that interval_ms controls typing speed. Since annotations provide little, the description carries the burden but only partially covers behavioral traits.

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 sentences, front-loaded with the primary purpose and followed by a concise safety warning. Every word earns its place, with no redundancy or filler. The structure is ideal for quick comprehension.

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 with only 2 parameters, and the output schema exists (though not shown), so return value documentation is covered. The description conveys the core action and a critical security constraint. However, it omits the prerequisite that a control must already be focused, which is important for correct usage in an agent context. It also does not mention any potential failure modes when typing into non-text fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain either parameter. While 'text' is somewhat self-evident from the tool's purpose, 'interval_ms' is only documented in the schema with a default of 12, giving no indication of its effect (e.g., delay between keystrokes). The description should compensate for the lack of schema descriptions but does not.

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 tool's function with a specific verb and object: 'Type bounded plain text into the currently focused control.' This distinguishes it from sibling tools like click, press_key, and scroll, which handle different input modalities. The phrase 'bounded plain text' also clarifies the text is not interpreted as commands or special keys.

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 clear context: the tool types text into the currently focused control. It also includes an explicit 'Never' list (passwords, tokens, recovery codes, payment data, terminal commands) which serves as a when-not guideline for sensitive content. However, it does not name alternative sibling tools or explicitly compare when to use this tool versus press_key or other input methods, so it falls short of a 5.

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