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

No annotations provided, so the description fully covers behavior: it describes the coordinate system (top-left origin), button mapping (1=left, 2=middle, 3=right), observe behavior (returns state in same call), settle_ms waiting (up to 5000ms), and failure condition (isError if instance down). This exceeds transparency expectations.

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 moderately concise with three sentences packing essential info. It front-loads the main action and parameters, but the second sentence about return values could be slightly more streamlined. Overall, 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?

Given 6 parameters, 0% schema coverage, and no output schema, the description is remarkably complete. It covers all parameters, return values, and failure semantics. No significant gaps remain for an AI 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?

With 0% schema coverage, the description compensates fully: it explains x,y as absolute pixel coords, button as integer with meaning, observe as 'screenshot'/'parse' for state, settle_ms as wait time with suggested range, and instance as targeted instance. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Click at absolute pixel coords (top-left origin) in an instance', providing a specific verb ('click') and resource ('instance'). It distinguishes from sibling tools like 'click_element' (which clicks UI elements) and 'double_click', making the 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?

The description gives usage context: 'use 400–1500 after anything that navigates or submits' for settle_ms, and explains that observe values 'screenshot'/'parse' save a round-trip. However, it does not explicitly state when not to use this tool versus alternatives like 'click_element', though sibling names imply the distinction.

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?

Discloses failure mode (isError with fix named), data staleness, and referential behavior for observe/settle_ms. With no annotations provided, the description fully bears the transparency burden and meets it well.

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 front-load the core purpose and essential guidelines. However, it could benefit from a brief parameter explanation, but overall 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?

Given 5 parameters, no output schema, and no annotations, the description covers usage context and failure behavior but lacks parameter details and full return semantics. Adequate but could be more 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?

Schema description coverage is 0%, yet the description does not explain the individual parameters (button, instance, observe, settle_ms). Only id usage is implied, and others are merely referenced to click(). This is insufficient.

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 specific action (click), resource (element by id), and context (from parse_screen, no coordinate guessing). It effectively distinguishes from sibling 'click' which likely uses coordinates.

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?

Explicitly instructs to run parse_screen first, explains staleness of ids, and provides guidance on failure recovery (fix named). Also references click() for observe/settle_ms parameters.

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 fully discloses behavioral traits: it waits for the display to stop responding before returning, returns a structured response, and fails under specific conditions. It also highlights the protected nature of instance 1, providing critical behavioral context.

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 and well-structured: a single sentence for the main action and return, followed by a sentence listing failure conditions. Every sentence adds essential information without redundancy.

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 simplicity (one parameter, explicit output schema implied), the description covers the tool's purpose, return value, failure modes, and a special case. It is sufficiently complete for an AI agent to understand and use the tool 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 schema has 0% description coverage, and the description does not explicitly define the 'instance' parameter beyond mentioning instance 1's special behavior. While it adds context via an edge case, it lacks a clear definition of valid instance numbers or how to obtain them (e.g., from list_instances), partially compensating for the schema gap.

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 explicitly states the verb 'Close an instance' and details what that entails: killing its app and Xephyr display and verifying shutdown. It clearly distinguishes this from sibling tools like launch_app, status, or list_instances by specifying the termination 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 provides guidance on when to use the tool (to close an instance) and explicitly states failure conditions—instance not running, survival of SIGTERM, or instance 1 being protected. It also gives an alternative method for instance 1 (stop from host with pkill Xephyr), offering clear usage boundaries.

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, so description carries burden. It specifies return structure, failure condition (instance down), and references click() for two parameters. Does not detail side effects or potential destruction, but covers key behavioral aspects.

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?

Extremely concise: three sentences front-load purpose, then return format, then reference and failure. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple tool: explains action, return, failure, and references for additional detail. Lacks parameter explanations and explicit sibling differentiation, but sufficient as minimal viable 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 coverage 0%, description does not explain parameters beyond 'absolute pixel coords' for x/y. The observe, instance, and settle_ms parameters are mentioned but not described; refers to click() but no details here. Minimal added 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?

Clearly states 'Double-click at absolute pixel coords in an instance' with concrete examples like 'open a file icon, select a word'. Distinguishes from sibling 'click' (single click) and 'click_element' (by element).

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 examples and references click() for observe/settle_ms, but does not explicitly state when to use versus alternatives like click_element or drag. Lacks exclusions or when-not-to-use guidance.

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 full burden. It describes the sequence of events (mouse-down, move, up), return format, and a failure condition (instance is down). It references observe/settle_ms from click(), adding context.

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 very concise (three sentences), front-loads the purpose and action, then covers return and failure. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers core behavior and return values, it lacks detail on many optional parameters (button, observe, instance, settle_ms) and does not specify timeout or edge cases. With 8 parameters and no output schema, more completeness would be beneficial.

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

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

Schema coverage is 0%, so description should add meaning. It explains x1,y1,x2,y2 as start and end points, and mentions button, observe, instance, settle_ms with a reference to click(). However, it does not elaborate on default values or behavior of all 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 clearly states it performs a drag action (mouse-down → move → up) between two points, and lists use cases (drawing, selecting, sliders). This distinguishes it from siblings like click or move_mouse.

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 mentions use cases but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings. The mention of failure when instance is down is a helpful constraint.

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 provided, so description carries the burden. It discloses return format, coordinate system (absolute pixels, top-left origin), and failure case. Does not explicitly state it's a read-only operation, but that is implied.

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

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

Three concise sentences front-loading the key information: what it returns, when to call it, and how to interpret vision. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers return schema, usage context, coordinate system interpretation, and failure condition. For a tool with one optional parameter and output schema, this is 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?

Schema coverage is 0%, so description must compensate. The parameter 'instance' is referenced in 'within THIS instance's display' but not explicitly listed or described. Does not explain default or behavior when omitted.

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 it returns screen size, vision backend, and server version. It also distinguishes itself from siblings like screenshot and parse_screen by explaining how vision tells you which to use.

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?

Explicitly says 'Call it once before coordinate math' and provides conditional guidance on how to use based on the vision field. Also mentions failure condition (isError) when instance is down.

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 fully carries the burden. It details Xephyr display creation, Chromium special flags and CDP port, D-Bus isolation, return structure, failure conditions, and cursor separation for parallel agents.

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?

Well-structured with front-loaded purpose and separate details. Slightly verbose with some redundancy (Xephyr mentioned twice), but every sentence adds value. Could be trimmed slightly without losing clarity.

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 complexity (isolated display launch, parallel agents), the description is comprehensive. It explains return fields, failure modes, and usage caveats. The existing output schema is described in detail, so no 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?

Schema description coverage is 0%, but the description thoroughly explains each parameter: 'command' is any shell command with examples, 'name' is optional with default empty, 'size' defaults to '1440x900'. This compensates fully for missing schema descriptions.

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 verb 'Launch', the resource 'GUI app in its OWN new Xephyr display/window', and the output 'return its instance id'. It effectively distinguishes from sibling tools like open_file (for files) and close_instance (for managing instances).

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 concrete command examples, special handling for Chromium and other GTK apps, and warns against sharing instances between agents. Lacks explicit 'when not to use' direction, but context strongly implies it's for launching new app instances.

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?

Since no annotations are provided, the description fully carries the burden. It details the return fields (ok, instance, dir, count, truncated, files), the 200-entry cap, sorting, and explains how files can be used by other tools (open_file, launch_app downloads). No behavior is left unclear.

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 paragraph that efficiently conveys the tool's purpose, return format, and usage context. It is front-loaded with the core function. Slightly dense, but every sentence adds value. Could be broken into bullet points for easier scanning.

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 role in a file management workflow, the description completely covers the return structure, limits, sorting, and relationships with siblings. The output schema exists, so return values are already documented; the description adds practical context for when and how to use the 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 single parameter instance is implied by the phrase 'The instance's staging folder' but is not explicitly described. Schema coverage is 0%, and the description does not explain that instance is an integer ID. Some compensation occurs through context, but a direct explanation would improve clarity.

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 lists the instance's staging folder contents and returns a file list. It distinguishes itself from siblings like open_file, upload_file, and launch_app by explaining how files in the staging folder are used and how the tool fits into workflows.

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?

Explicit guidance is provided: call this after a download to confirm file arrival; browser uploads still go through upload_file. The description also notes the return structure with a 200-entry cap and sorting, giving the agent clear when-to-use 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 provided, the description fully covers behavioral traits: it reveals that the tool probes displays :1–:12 to find sandboxes started externally, notes that instances not launched by this process show 'unknown' name/command, and describes the exact JSON return structure.

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 with two clear paragraphs: first defines the tool and its output, second explains an important behavioral nuance. Every sentence adds value without redundancy.

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 parameters and an output schema exists, the description still explains the return format and key behavioral details (external instance detection). This is complete and sufficient for an agent to use the tool 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 parameters, so per guidelines the baseline is 4. Since there are no parameters to describe, the description appropriately adds no parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all running app windows (instances) and specifies the returned fields (id, display, name, command, up). It is a unique resource distinct from sibling tools like click or launch_app, making its purpose unmistakable.

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 context: 'Use it to discover what you can drive and to verify an instance is up before acting.' However, it does not explicitly mention when not to use it or contrast with alternatives, so it lacks 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 discloses that it does not click, returns a specific structure, fails if instance is down, and is useful for hover states. This is sufficient for a simple pointer move.

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

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

Three concise sentences, front-loaded with purpose, each adding value: behavior, return, use case, and failure condition. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 3 parameters and no enums, the description covers purpose, return values, use case, and error condition, making it complete for an agent to select and 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 coverage is 0%, so description should compensate. It mentions 'absolute pixel coords' for x and y and refers to 'instance', but does not detail ranges or units. The schema itself is clear enough for simple integer coordinates.

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 moves the mouse pointer to absolute pixel coordinates without clicking, and distinguishes it from sibling tools like click and double_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 provides a clear use case for hover states and suggests following with screenshot, but does not explicitly mention when not to use or name alternatives.

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 fully discloses behavioral traits: it opens on existing display, runs specified app or xdg-open, resolves relative paths, returns specific fields, fails if file/app doesn't exist, starts asynchronously (suggesting screenshot confirmation), and notes GTK apps get same handling as launch_app. No contradictions.

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 reasonably concise with two paragraphs. The first sentence front-loads the core purpose and key constraint. Every sentence serves a purpose, though the structure could be slightly more streamlined (e.g., grouping related details).

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 complexity (3 params, no annotations, output schema exists), the description is complete: it covers purpose, usage guidelines, parameter behavior, failure modes, async nature, and alternatives. The output schema is referenced by naming returned fields, fulfilling completeness.

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?

Despite 0% schema description coverage, the description adds meaningful semantics: it explains the app parameter (optional, runs that app), filepath (required, resolves relative to staging folder), and implicitly references instance (existing display). It does not detail the instance parameter's type or default, but the schema covers those.

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 opens a local file in an app on an existing instance's display, explicitly distinguishing it from creating a new instance. It specifies the exact resource (local file) and context (existing display), 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?

The description provides explicit guidance on when to use this tool versus alternatives: it says to use upload_file() for browser file uploads, and contrasts with launching a new instance. It also explains relative path resolution against the instance's staging folder, referencing list_files for 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 fully discloses behavior: it returns a detailed JSON structure, saves a Set-of-Mark image, explains backend options, element cap of 300 with truncation flag, and id validity scope. This is comprehensive for an agent.

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 relatively long but well-structured with bullet-like formatting and clear sections. Each part adds value, though it could be slightly more concise by removing redundant phrasing.

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 complexity (multiple backends, return format, image saving, truncation, id validity), the description is quite complete. However, it lacks explanation of the parameters, which reduces completeness for a tool with two undocumented parameters. The output schema exists to document return values.

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%, meaning the schema itself provides no parameter descriptions. The tool description does not explain the two parameters (instance, box_threshold) at all, leaving the agent without guidance on what they control. This is a significant gap.

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 it detects on-screen elements and returns them with ids and pixel centers. It uses a specific verb 'detect' and resource 'on-screen elements', and distinguishes from sibling tools like click_element (which uses the ids) and screenshot (which is a raw image).

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 clear context on when to use this tool (to detect elements for clicking) and explains backends (local, basic, none) with their trade-offs. It also notes that ids are only valid until screen changes, implying re-parse after navigation, but does not explicitly state when not to use it versus alternatives.

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?

In the absence of annotations, the description covers return format (JSON with ok, action, instance, detail), failure conditions, and references observe/settle_ms as used in click(). It does not detail behavior for default parameter values or all edge cases, but provides sufficient transparency.

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 with 3-4 sentences, front-loads the action, and includes examples and a workflow tip. No redundant information, but the reference to click() could be more self-contained.

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 4 parameters and no output schema, the description covers the primary purpose, examples, return format, failure cases, and a usage scenario. It lacks detailed parameter descriptions but is adequate for a simple key-press 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 schema has 0% description coverage, so the description must add meaning. It explains the 'keys' parameter with valid examples and syntax, but does not describe 'observe', 'instance', or 'settle_ms' in detail (just references click()). This adds partial value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool presses a key or combo using xdotool syntax, and provides specific examples like 'Return', 'ctrl+a', etc. It distinguishes itself from sibling tools like click, double_click, drag, scroll, and type_text by focusing on key presses.

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 explicit usage context, such as browser navigation sequence ('ctrl+l' → 'ctrl+a' → type_text(url) → 'Return'), and notes failure conditions (invalid keysym or dead instance). However, it does not explicitly exclude alternative 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?

Despite no annotations, the description discloses that it is a read-only snapshot operation, notes it fails if the instance is down, and implies it is non-destructive. However, it does not explicitly state it does not modify state or require special permissions, but the nature of a screenshot makes that clear.

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 concise sentences with key information front-loaded: purpose, alternatives, and failure condition. No redundant or extraneous content.

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 screenshot tool with one parameter and no output schema, the description covers purpose, usage guidance, failure condition, and return format (PNG). It is fully sufficient to enable correct 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?

Only one parameter (instance) with 0% schema coverage. The description mentions 'an instance's window' hinting that the parameter identifies the instance, but does not explain its default value or range. Barely compensates for the lack of schema documentation.

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?

Clearly states it takes a full-display PNG screenshot of an instance's window. Explicitly distinguishes itself as the only way to see the screen and contrasts with parse_screen and observe='screenshot' on action tools.

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 explicit guidance: 'always look before you act', recommends using parse_screen for element list with coordinates, and suggests prefering observe='screenshot' on action tools to act and see result in one call. Clearly outlines when to use this tool versus alternatives.

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 fully discloses behavior: direction semantics, return format, unit definition, prerequisite actions, error conditions, and references to click() for observe/settle_ms. This exceeds the burden.

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?

Description is compact (two sentences plus a note about returns and error conditions). Every sentence provides value, no fluff. Front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and moderate complexity, the description covers return format, behavioral nuances (unit, prerequisite, errors), and parameter interpretation. It is complete enough for an agent to use 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?

Since schema has 0% parameter descriptions, the description adds crucial meaning: amount direction/unit, observe/settle_ms reference to click(). Instance is not explained but defaults to 1. Significant value added, but instance could be 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 clearly states the tool scrolls the wheel at the current mouse position, specifying positive/negative direction. It distinguishes from sibling tools like click, drag, and move_mouse by focusing on wheel 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?

It provides guidance: scrolling targets the window under the pointer, and recommends moving the mouse/clicking there first. It also notes failure conditions (amount=0, dead instance). Implicitly suggests not using without prior pointer positioning, but lacks explicit alternatives.

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?

Explicitly declares 'No side effects' and read-only nature. Details the structure of the response, including fields like 'vision' and 'deps', with explanations of their meaning.

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?

Concise and front-loaded: first sentence gives the core purpose, followed by a succinct breakdown of the return value. Every sentence 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?

Given zero parameters and the presence of an output schema, the description fully covers the tool's behavior, including what the output contains and that it has no 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?

No parameters exist (input schema has zero properties, 100% coverage), so the description does not need to add parameter explanations. Baseline 4 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?

Description clearly states it returns combined server and sandbox status in a single read-only call. It is distinct from sibling tools like click, screenshot, etc., which are not status-related.

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?

Explicitly recommends 'run this first' and 'when filing bug reports', providing clear use cases. No alternative tools needed for status queries.

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 fully discloses the dual method (xdotool vs clipboard), the rationale for the clipboard fallback (toolkit compatibility), and the fallback failure behavior (isError if xclip missing). Also documents the return format.

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 well-structured with the main purpose front-loaded. Slightly verbose in explaining the unicode workaround, but the detail is necessary for transparency.

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?

Good coverage of core behavior and failure modes, but lack of detail on observe/instance/settle_ms parameters leaves a gap. Since there is no output schema, the return format is described, which is helpful.

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

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

Schema coverage is 0%, yet only 'text' is explained (typed input). The other three parameters (observe, instance, settle_ms) are merely referenced with a direction to 'see click()', providing no independent semantics. This is insufficient.

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 'Type into the focused field — unicode-safe', which clearly indicates the action (type) and resource (focused field). It distinguishes from siblings like click or press_keys, though not explicitly naming 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?

Explicitly instructs to click the field first to focus it. Provides context on when the clipboard fallback is used (non-ASCII characters) and failure conditions (missing xclip). Does not list when to avoid this tool in favor of alternatives.

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 provided, but description fully covers behavioral traits: uses CDP, requires Chromium started by launch_app, selector targets main page, advises clicking first if input is dynamic, and details return format/failure reasons. Adds context on observe/settle_ms referencing click().

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?

Every sentence adds value: purpose, when to use, how to use, edge cases, return values, and references. Front-loaded with main action. 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?

Given 5 parameters, no output schema, and no annotations, description provides complete context: prerequisites (Chromium, launch_app), dynamic input handling, return format, failure reasons, and distinction from sibling tools (open_file). No 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?

Despite 0% schema description coverage, description explains each parameter: filepath (required local path), selector (default first input), instance (integer), observe and settle_ms (see click()). Adds meaning beyond the schema definitions.

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?

Description explicitly states the tool attaches a file to a page's file input via CDP, distinguishes from native file picker, and specifies its use for all browser uploads. Verb 'attach' and resource 'file input' are 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?

Explicitly advises against clicking upload buttons for dialogs (since native picker is invisible and hangs renderer), prescribes using this tool instead. Also contrasts with native apps: suggests open_file() for visible dialogs. Clear when-not and alternatives.

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 provided, but description fully discloses behavior: cap at 10000 ms, returns {'ok', 'action', 'requested_ms', 'waited_ms', 'clamped'}, explains 'clamped' flag meaning when cap exceeded. No contradictions.

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: first defines purpose and cap, second explains return structure and alternative. No redundant words, information is front-loaded and 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 simple wait tool, description covers return values, behavior at cap, and alternative (settle_ms). No output schema visible but description provides details. Complete for its complexity.

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

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

Only one parameter 'ms' (integer) with 0% schema description coverage. Description adds the cap constraint (10000 ms) but does not explicitly state the parameter represents milliseconds. The tool name 'wait_ms' implies milliseconds, but description could be clearer.

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?

Clearly states it's a 'wait' tool for page load or app draw. The verb 'wait' and resource implied (time) with specific use cases. Differentiates from siblings by mentioning 'settle_ms' as an alternative for observing results in the same call.

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 clear context: wait for page load or app draw, capped at 10000 ms. Suggests preferring 'settle_ms' on the action to observe the result simultaneously. Lacks explicit when-not-to-use but covers key usage guidance.

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