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

With no annotations, the description carries the transparency burden. The read-only verb 'Get' and the Returns line disclose the operation and response envelope, but the description does not address what happens when the selector matches no element or the attribute is missing, nor does it explicitly guarantee no 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 compact and well-structured: a one-sentence purpose, a focused Args block, and a Returns line. Every sentence earns its place and the most important information is front-loaded.

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 essential invocation details and return shape are present, which is enough for a simple getter. Still, with no annotations, the lack of failure behavior and selector-match ambiguity leaves some contextual gaps for an agent deciding among the many sibling browser 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?

All three parameters are defined beyond the bare schema: serialno is sourced from list_devices, selector is identified as a CSS selector, and attribute includes an href example. This fully compensates for the 0% 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 opens with a specific verb and resource: 'Get one attribute of an element.' This clearly distinguishes it from sibling browser tools such as browser_text, browser_exists, and browser_state, and the argument descriptions reinforce that it reads a single CSS-selected attribute.

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 purpose sentence implies the tool should be used when a single attribute value is needed, and 'from list_devices' gives a prerequisite for serialno. However, it never explicitly states when not to use it or how to choose between browser_attribute and alternatives like browser_text or browser_execute.

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 only states that a click is performed and returns a JSON response, but omits important context such as whether the element must be visible, whether the click triggers navigation, prerequisites like the browser being open, or error handling for missing elements. This is a significant gap for a mutation-like 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 extremely concise, with a single-sentence purpose followed by a structured list of arguments and a return note. Every sentence earns its place, and the action is front-loaded. No unnecessary verbiage or repetition of schema 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?

Although the tool has only two parameters and an output schema exists (per context signals), the description still feels incomplete. It does not mention prerequisites (e.g., browser must be running, serialno must correspond to an active device), side effects, or what the JSON response contains beyond being a generic API response. An agent might call this tool without understanding the environment requirements, leading to errors.

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 explains serialno as 'from list_devices' and selector as 'A CSS selector,' which is useful and goes beyond the schema's bare property names. However, it does not elaborate on what constitutes a valid selector, what happens if multiple elements match, or the format expected for serialno. It provides basic meaning but not comprehensive semantics.

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: 'Click the element matching a CSS selector.' It specifies the verb (click) and the resource (element matched by selector), making the tool's purpose unambiguous. The name and sibling context (browser_* vs mobile_* vs computer_*) further distinguish it, so an agent can easily tell it apart from mobile_tap or computer_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?

No explicit guidance on when to use this tool versus alternatives like mobile_tap or computer_click is provided. The usage is implied by the name and the serialno parameter (browser device), but there is no statement such as 'use this for browser interactions only' or 'use mobile_tap for mobile devices.' It does not actively mislead, but it leaves the choice 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?

With no annotations, the description carries the full burden of disclosing side effects and behavior. It states that the operation stops the browser/CDP endpoint, but does not disclose consequences such as closing all tabs, invalidating the session, requiring a previously launched browser, or whether the operation is idempotent. The 'Returns: JSON response from the API' line adds little behavioral detail.

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 short and front-loads the main action. The Args and Returns sections are minimal and each line serves a clear purpose. There is no redundant phrasing or unnecessary examples.

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 one parameter and an output schema, so the description covers the essential invocation details. However, for an agent choosing among many browser and mobile navigation tools, it lacks any mention of side effects or when browser-level close is appropriate versus tab-level or app-level operations. This leaves a noticeable 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 provides no description for serialno (0% coverage), so the description compensates by explaining that serialno is the browser device serial number obtained from list_devices. This is sufficient for the single required parameter, though it could also clarify what happens if the serialno is invalid or stale.

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 ('Stop the browser / CDP endpoint') and identifies the resource, distinguishing it from tab-level operations like browser_tab_close. It is not a tautology and gives the agent a concrete sense of what the tool does. However, it does not explicitly contrast itself with related sibling tools like browser_launch or browser_tab_close_all.

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 browser_tab_close, browser_tab_close_all, or mobile_stop_current_app. The only contextual hint is that serialno comes from list_devices, which is a prerequisite rather than a usage guideline.

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 prominently warns 'Danger tier: the script runs with the page's own privileges, the same reach as shell access to the browser profile', which is a strong behavioral disclosure. It also mentions the JSON envelope return. However, it doesn't discuss other potential side effects (e.g., page state changes, blocking), though the danger warning largely covers this.

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 a danger warning first, then Args and Returns sections. Every sentence serves a purpose, and it is concise with 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 has an output schema, so return values need not be detailed; the description mentions the JSON envelope. It covers both parameters, the danger level, and the source of serialno. It lacks explicit usage context (covered under usage_guidelines), but for a simple JS evaluation tool it is adequately 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%, so the description fully compensates by explaining both parameters: serialno ('from list_devices') and script ('JavaScript source to evaluate'). This adds clear 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 clearly states 'Evaluate JavaScript in the page' with a specific verb and resource. This is unique among siblings, as no other tool offers arbitrary JS execution, so it is easily distinguished.

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 on when to use this tool versus other browser actions. It implies use for custom JS but doesn't mention alternatives or exclusions, leaving the agent to infer from the name and 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. It discloses the return format (JSON envelope reporting existence) but does not explicitly state that the operation is side-effect-free, whether it waits for the element, or any timing behavior. This is a modest disclosure for a read-like 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 concise and structured with args and returns clearly listed. It is efficient with no wasted words, though it could be slightly more detailed without becoming verbose.

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 existence check, the description provides essential information: purpose, parameters, and return shape. However, it omits details like whether the tool waits for the element, what 'present' means in edge cases, or any error behavior. Given the low complexity, this is adequate but not 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 description adds meaningful context for both parameters: serialno is explicitly tied to list_devices, and selector is identified as a CSS selector. Since schema coverage is 0%, this compensates well, though it could elaborate further on selector syntax or expected value formats.

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 ('Check') and resource ('whether an element is present'), making the primary purpose clear. However, it does not explicitly differentiate from related siblings like browser_state or mobile_dump_hierarchy, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives. It does not state typical usage scenarios, exclusion conditions, or reference any sibling tools. Usage context must be inferred by the agent from the verb 'check'.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the key behavior of clearing the input before typing, which is consequential and not obvious from the name. However, it does not mention whether the element must be visible, whether the tool waits, or what happens on failure, leaving some ambiguity.

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-structured: one purpose sentence, then Args and Returns sections. It is front-loaded with the core action and contains no filler or redundant restatement of the tool name.

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 three-parameter tool with an output schema, the description covers the purpose, all parameter semantics, and the return type sufficiently for an agent to call it correctly. The main gap is lack of usage differentiation from browser_input, but that is already scored under usage guidelines.

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 compensates fully: serialno is tied to list_devices, selector is identified as a CSS selector, and value is described as the text to type. Each parameter gains meaning beyond its bare name and type.

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 first sentence 'Clear an input and type a value into it' states a specific verb and resource, and the selector parameter makes clear this targets a browser input. It is distinguishable from most siblings like mobile_tap or browser_navigate, but it does not differentiate itself from the closely named browser_input, which may sound like the same 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 gives no guidance on when to use browser_fill versus browser_input, browser_click, or mobile_input_text. There are no exclusions, alternative recommendations, or context hints beyond the action itself, so an agent has to infer when this tool is the right choice.

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 full responsibility for behavioral disclosure. It only states the action and a generic 'Returns: JSON response from the API.' It does not mention edge cases (e.g., empty history), potential side effects, or whether it waits for page load. This is minimal and insufficient for a tool with no annotation support.

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—two short paragraphs with no fluff. The purpose is front-loaded, and the parameter explanation is direct. 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 the simplicity of the tool, the description is still incomplete. It lacks information about error handling, behavior when history is empty, or what the JSON response contains. With no annotations and a generic return statement, an agent has limited understanding of what to expect. More behavioral detail would be valuable.

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 does explain that 'serialno' is 'The browser device serialno, from list_devices,' which adds context about the parameter's origin. However, it provides no format or constraints, so it is only partially helpful.

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 and resource: 'Navigate back in the browser history.' It clearly conveys the action. However, it does not explicitly differentiate from sibling tools like browser_go_forward or browser_navigate, so it misses the top score.

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 usage is implied by the action: use it to go back in browser history. But there is no explicit guidance on when to prefer this over alternatives, nor any exclusions or prerequisites. It lacks a clear when-to-use vs. when-not-to-use statement.

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, but it only restates the action and generic return type. It does not disclose side effects on browser state, prerequisites such as an active browser session, or behavior when there is no forward history entry.

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, front-loaded with the action, and has clear Args/Returns sections. The generic 'JSON response from the API' line is somewhat redundant given the existing output schema, but it does not bloat the 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?

For a one-parameter tool the description covers the action, parameter source, and return. It remains incomplete because it does not mention the forward-history edge case or any browser-session prerequisite, which an agent could need to predict failure.

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 provides only the property name and type with zero description coverage. The description adds meaning by identifying serialno as the browser device serialno and pointing to list_devices as its source.

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 opens with a specific action and resource: 'Navigate forward in the browser history.' This clearly distinguishes it from sibling browser_go_back and the naively similar browser_navigate.

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

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

No explicit when-to-use or when-not-to-use guidance is given, and no alternative is named. The intended context (after going backwards, when forward history exists) is only implied by the word 'forward' and the existence of browser_go_back.

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 the key limitation that browser-chrome shortcuts are not reachable because CDP drives the page, not the browser UI. It also states that editing shortcuts act on the page, but it does not mention potential side effects, error handling, or whether the action waits for page responses.

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-structured, with the core purpose front-loaded and a clear Args/Returns format. The additional context about editing shortcuts and browser-chrome limitations is relevant and earns its place without padding.

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 two-parameter hotkey tool, the description covers the essential aspects: how to obtain serialno, the format of keys, a usage example, and the return type. It omits a list of valid modifier keys (e.g., Meta, Control, Shift) but that is not strictly necessary for a simple hotkey action. The presence of an output schema (though not provided) reduces the need to detail return structure.

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 the description must fully explain parameters. It defines serialno as 'the browser device serialno, from list_devices' and keys as 'the keys to press together', with a concrete example. This adds meaning beyond the schema's bare types and clarifies the expected format.

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 ('Press keys together') with a concrete example ('Meta', 'a' to select all). It distinguishes itself from browser-chrome shortcuts by explaining that CDP drives the page, not the browser UI, and specifies that editing shortcuts act on the page, 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?

It provides clear context by noting that editing shortcuts (select-all, cut, copy, undo, redo) act on the page and that browser-chrome shortcuts like Control+t are not reachable. It also directs users to get serialno from list_devices, but it does not explicitly name alternative tools (e.g., computer_hotkey) or give a when-not-to-use beyond the browser-chrome exclusion.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states the mechanism (CDP Input.insertText), the reliability for CJK, and that it returns a JSON response, but it does not mention prerequisites (e.g., element must be focused), side effects (e.g., whether existing text is replaced), or error conditions. Some transparency is present, but not comprehensive.

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, with a one-line summary, a note on the mechanism, and clearly labeled Args and Returns sections. Every sentence provides value, and the information is front-loaded with the 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 tool with two parameters and an output schema, the description covers purpose, parameters, and the return type adequately. It could add more context about preconditions (e.g., focus requirement) or failure modes, but given the tool's simplicity, it is largely 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%, so the description fully compensates by explaining each parameter: serialno is from list_devices, and text is the text to insert. This adds meaningful context beyond the bare schema, making parameter usage clear.

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 inserts text into the focused page element, using a specific verb and resource. It further distinguishes itself by noting the use of CDP Input.insertText, which is reliable for CJK, contrasting with synthesized key events. This gives a precise, unambiguous 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?

The description implies when to use this tool (for inserting text, especially for CJK) but does not explicitly state when not to use it or name alternatives like browser_fill or computer_type_text. The contrast with synthesized key events hints at a trade-off but does not provide explicit routing 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?

No annotations are provided, so the description must disclose behavioral traits. It only states 'Start the browser / CDP endpoint' and mentions a JSON response. It does not disclose side effects, idempotency, or any setup requirements, leaving the agent with minimal behavioral understanding.

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, with clear 'Args' and 'Returns' sections. The purpose is front-loaded, and every sentence contributes meaning 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?

The tool has a single parameter and an output schema, so the description does not need to explain return values in detail. It provides the key prerequisite (serialno from list_devices) and a basic return type. However, it lacks context on potential prerequisites like device connection state or the meaning of CDP endpoint, making it adequate but not 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 description coverage is 0%, so the description must compensate. It explains that serialno is 'The browser device serialno, from list_devices', which adds meaning beyond the bare schema by specifying its origin and purpose. This is sufficient for a single 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 action 'Start the browser / CDP endpoint' which clearly identifies the tool's function. It does not explicitly differentiate from sibling browser tools, but the purpose 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?

No explicit guidance on when to use this tool versus alternatives. It mentions the serialno comes from list_devices, which is a useful prerequisite, but does not say when to use it or what to do after launching.

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 'Navigate the current tab to a URL' and 'Returns: JSON response from the API.' It does not disclose potential side effects, error behavior, whether it waits for page load, or any permissions required. The description is minimal and lacks the transparency expected for a navigation 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 concise and structured with clear 'Args' and 'Returns' sections. The purpose is front-loaded in the first sentence. It avoids unnecessary verbosity, though the 'Returns' section is generic and could be omitted if an output schema is available. Overall, it is efficient and well-organized.

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 a simple interface with two well-explained parameters, and an output schema is indicated as present (though not shown). The description says 'Returns: JSON response from the API,' which is vague but acceptable if the output schema provides specifics. However, it lacks details on behavior like waiting for page load or error handling, which could be important for an agent to call it correctly in a workflow. Given the low complexity, a score of 3 is appropriate; it is adequate but has 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 description coverage is 0%, so the description must compensate. It explains both parameters: serialno is 'The browser device serialno, from list_devices' and url is 'The destination URL.' This adds meaningful context beyond the raw schema types, clarifying the source of serialno and the nature of the URL. It provides sufficient semantics for an agent to correctly populate both arguments.

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 and resource: 'Navigate the current tab to a URL.' It clearly distinguishes this from sibling tools like browser_refresh, browser_go_back, and browser_go_forward by focusing on URL navigation. The addition of 'current tab' clarifies scope, and the args section reinforces the 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?

The description does not provide guidance on when to use this tool versus alternatives. It mentions that serialno comes from list_devices, which is a prerequisite, but there is no explicit statement about when to use this tool instead of browser_refresh, browser_go_back, or other navigation tools. No exclusions or conditions are given.

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 clearly states the action and that a JSON response is returned, but it does not mention side effects of reloading, such as losing unsaved page state or whether the reload waits for completion.

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-structured, with an action-first sentence followed by clearly labeled Args and Returns sections. There is no redundant or misleading 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 one-parameter tool with an output schema, the description covers the essential information: what it does, the parameter source, and the return format. It is slightly incomplete because it does not state the need for an active browser page, but that is reasonably implied by 'current page.'

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 explains that serialno is 'The browser device serialno, from list_devices,' adding useful sourcing context beyond the schema's bare string type.

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 and resource: 'Reload the current page.' This is distinct from sibling navigation tools like browser_navigate, browser_go_back, and browser_go_forward, so an agent can immediately tell 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?

No guidance is provided on when to use this tool versus alternatives such as browser_navigate or browser_go_back. It also does not mention prerequisites like having an already-open page, though the parameter source is noted.

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. It only states 'Returns: JSON response from the API' with no mention of side effects, required page state, permissions, or error behavior. For a mutation-like action on a dropdown, this 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 efficient: one line for purpose, then a clear Args list, then Returns. It is front-loaded with the action and wastes no 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 select action, the description covers the parameters and return type. However, it lacks any preconditions (e.g., page must be loaded), error scenarios, or interaction with waiting behavior. Given an output schema exists (per context signals), return format is presumably defined there, so the main gap is usage context and edge cases.

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 explain parameters. It does: serialno is identified as from list_devices, selector is a CSS selector for the select element, and value is the option value to select. This adds meaning beyond the bare schema titles, though the meaning of 'value' could be ambiguous (visible text vs. value attribute).

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 'Pick an option in a dropdown' and the selector parameter clarifies it targets a 'select element', distinguishing it from sibling tools like browser_click or browser_fill. However, it does not explicitly name alternatives or contrast 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?

There is no guidance on when to use this tool versus other browser interaction tools such as browser_click or browser_fill. The description only states what it does, not when it is the appropriate choice.

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 states it returns a JSON envelope with browser state, which is transparent about the output. However, it doesn't mention whether the operation is read-only (though 'Get' implies it), any side effects, or potential error conditions like an unopened browser. The description is adequate for a simple read but lacks explicit safety or prerequisite 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 extremely concise: two short paragraphs, front-loaded with the core purpose, then args and returns. Every sentence adds value with no redundancy. The structure is clean and easy to parse.

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 an output schema (as indicated by context), so the description doesn't need to detail return values beyond mentioning the JSON envelope. It covers the single parameter and its source. It's complete for a simple read-only operation, though it could explicitly mention if the browser must be open, but that's implied by 'browser state' and 'from list_devices'.

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 zero description coverage for the parameter, but the description compensates by explaining 'serialno: The browser device serialno, from list_devices.' This adds meaning beyond the raw schema, telling the agent where to obtain the value and its purpose. For a single-parameter tool, this is fully sufficient.

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 specific resource: current URL, title, viewport, and tab count. This distinguishes it from navigation or manipulation tools like browser_navigate or browser_tabs, which focus on changes or tab-specific actions. It's unambiguous and actionable.

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 for reading browser state but doesn't explicitly state when to use it vs. alternatives. It mentions 'from list_devices' for the parameter, which hints at a prerequisite, but there's no explicit guidance on when to prefer this over other browser inspection tools like browser_tabs or browser_text. Usage context is inferred rather than 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core action and the return value, but does not disclose what happens when closing a tab (e.g., active tab behavior, failure modes, whether the operation is irreversible, or permissions required). For a destructive/state-changing action, 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 compact and well-structured: a one-line purpose followed by clear Args and Returns sections. There is minimal waste, and each section is immediately scannable for an agent.

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-required-parameter tool with an output schema, the description is mostly adequate: it identifies the action and tells the agent where to obtain both arguments. However, it lacks usage boundaries and does not mention behavioral caveats or failure cases, which are important for an agent selecting among many browser-tab 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?

Schema description coverage is 0%, so the description must compensate; it does by specifying the source for each parameter: serialno comes from list_devices and tab_id comes from browser_tabs. This adds practical meaning beyond the schema's type/title fields, though it stops short of describing formats or constraints.

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 begins with a specific verb and resource: 'Close one tab.' It clearly distinguishes itself from sibling operations like browser_tab_close_all by emphasizing a single tab, and from navigation/switch operations. An agent can tell exactly what this tool does without needing to inspect schemas.

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

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

The description gives no guidance on when to use this tool versus alternatives such as browser_tab_close_all, browser_tab_switch, or browser_tab_close. It only explains where to source the parameters ('from list_devices', 'from browser_tabs'), not the conditions or scenarios in which this tool is the right choice.

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?

There are no annotations, so the description must carry behavioral disclosure. It does state the core effect ('Close every tab') and that it returns a JSON response, but it does not mention whether the action is irreversible, whether unsaved tab state is lost, or any side effects beyond tab closure. This is acceptable 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 extremely concise and front-loaded. The main action is stated first, followed by compact Args and Returns sections. Every sentence earns its place with no redundant wording.

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 an output schema, the description covers the action, argument source, and return type. It does not provide usage alternatives or deeper consequences, but the tool's low complexity makes the description reasonably 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%, so the description must clarify the parameter. It explains that serialno is 'The browser device serialno, from list_devices,' adding meaning beyond the schema's type-only definition and pointing to the correct source 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 uses a specific verb and resource: 'Close every tab.' This clearly distinguishes it from the sibling tool browser_tab_close, which implies closing a single or selected tab. The action 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?

The description tells the user to pass a serialno from list_devices, but gives no guidance on when to choose this tool over browser_tab_close or any alternatives. There are no exclusions or context signals such as 'use this when you want to end the entire browser session.'

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 states it opens a new tab, which implies a mutation, but does not mention side effects like focusing the tab, whether the new tab is activated, or whether the browser must already be launched. The return value is described only as 'JSON response from the API,' which is vague and uninformative. The description fails to disclose any behavioral nuances beyond the obvious 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 exceptionally concise: a one-line purpose, a clear args section with each parameter on its own line, and a returns line. No redundant information or fluff. It is front-loaded with the action and structured for quick scanning, making it easy for an agent to parse.

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 an output schema exists, the vague 'JSON response from the API' might be acceptable. However, the description omits important contextual details such as whether the browser must already be running, whether the new tab becomes active, or any error conditions. It does mention the source of serialno, which is a useful prerequisite. Overall, it covers the basics but lacks behavioral context that could prevent incorrect 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 has zero descriptions (0% coverage), so the description must compensate. It does add meaningful context: serialno is explicitly defined as 'The browser device serialno, from list_devices,' which tells the agent where to obtain it. The url parameter is simply 'The URL to open,' which is self-explanatory but still clarifies its role. This exceeds the baseline for a tool with low schema coverage, though it could add more detail about URL format or expected scheme.

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 and resource: 'Open a new tab at a URL.' This clearly distinguishes it from sibling tools like browser_navigate (which likely navigates the current tab) or browser_tab_switch. The purpose is unambiguous and directly actionable.

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 alternatives such as browser_navigate, browser_tab_switch, or browser_tabs. It only lists arguments, with a hint that serialno comes from list_devices, but lacks any context about prerequisites or situations where this tool is preferred. The when-to-use information is entirely 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?

No annotations are provided, so the description carries the full burden. It clearly indicates this is a read-only listing operation and describes the return shape as a JSON envelope carrying tabs and their IDs. For a simple list operation, this is adequate behavioral disclosure.

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 front-loaded with the core action. The Args and Returns sections are minimal and every sentence contributes useful information, with no filler or repetition.

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, read-only tool with an output schema, the description covers everything needed: what the tool does, where the parameter comes from, and what the response contains. There are no significant gaps for an agent 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?

Schema description coverage is 0%, but the description compensates by explaining that serialno is 'The browser device serialno, from list_devices.' This adds meaningful context beyond the schema's bare 'Serialno' title, telling the agent where to obtain the value.

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 opens with 'List the open tabs,' a specific verb and resource that is distinct from sibling tools like browser_tab_open, browser_tab_close, and browser_tab_switch. It also notes that the returned data includes tab IDs, which clarifies what the tool produces.

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 such as browser_state or browser_tab_switch. The only procedural hint is that serialno comes from list_devices, which addresses parameter sourcing but not use-case 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It only states the action and a vague return type ('JSON response from the API'). It does not mention side effects (e.g., whether the current tab is closed), prerequisites, reversibility, or error handling. This is a significant gap for a tool that changes browser state.

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 and front-loaded with the main purpose. However, it is so brief that it lacks essential behavioral context. While it follows a clear Args/Returns structure, the content is sparse. It is not verbose, but it under-specifies, which is not a positive form of conciseness.

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 two simple parameters and no annotations, the description is incomplete. It does not explain what the returned JSON contains, what errors might occur, or what happens to the previous tab. Even though the operation is conceptually simple, the lack of any output schema description or behavioral details makes it insufficient for an agent to call it confidently.

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 descriptions for parameters (0% coverage), so the description must compensate. It adds the source of each parameter ('from list_devices' and 'from browser_tabs'), which is useful. However, it does not explain the format or constraints of tab_id (e.g., whether it is an index or a handle), leaving room for ambiguity. The added value is minimal beyond schema titles.

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 ('Focus one tab') with a specific resource (a browser tab). It is not a tautology and is distinct from sibling actions like open/close. However, it does not explicitly contrast with siblings such as browser_tab_open or browser_tab_close, so it falls short of a 5.

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

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

The description provides minimal usage context by noting that tab_id comes from browser_tabs and serialno from list_devices, but it gives no guidance on when to use this tool versus alternatives (e.g., browser_tab_open to create a new tab). There are no exclusions or conditions for selection, leaving the agent to infer usage.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return envelope and that serialno comes from list_devices, but it stays silent on error behavior, invalid selectors, non-existent elements, and whether it waits for the element. This is adequate for a simple read operation 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 tightly packaged: one purpose line, two one-line args, and one return line. No filler; the Args/Returns structure makes it easy to scan.

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 2-parameter read tool with an output schema present, the description covers the operation, both parameters, the origin of serialno, and the return shape. It lacks edge-case behavior and explicit sibling differentiation, but nothing essential to a basic call 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?

Schema coverage is 0%, yet the description adds meaningful semantics for both required parameters: serialno is tied to list_devices and selector is identified as a CSS selector. This goes beyond the raw names in the schema, though it stops short of examples or selector scoping 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 opens with a concrete operation — 'Get an element's text content' — giving a clear verb and resource. It is readily distinguishable by purpose from nearby browser tools like browser_attribute or browser_state, though it doesn't explicitly name the distinction.

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 intended use is implied by the one-liner: call this when you need the text content of an element in the browser session. It does not, however, state when to prefer browser_attribute or browser_state, nor does it give exclusions, so guidance beyond the obvious is 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 and does so thoroughly. It discloses that the command runs unsandboxed as the desktop user, that /bin/sh or cmd.exe is used so bash-only syntax may fail, and that non-zero exits are returned in data.exitCode rather than as tool errors. This is exactly the behavioral context an agent needs for a dangerous 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 tight and well-organized: a one-line purpose, a danger warning, exit-code semantics, then parameter and return docs. Every sentence contributes essential information, and the most safety-critical points are front-loaded.

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 risky shell-execution tool with no annotations, the description is complete. It covers safety, shell flavor, exit-code behavior, timeout defaults, parameter sourcing, and the return envelope. An agent has everything needed to invoke it correctly without guessing.

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 documents all three parameters meaningfully. It explains serialno comes from list_devices, command is the shell command, and timeout is in seconds with the critical clarification that omitting it or using 0 applies the server's 120s default. This adds real value 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 states a specific verb and resource: 'Run a shell command on the host machine that owns this device.' This clearly distinguishes computer_bash from on-device tools like mobile_bash and from higher-level computer interaction tools, giving an agent enough to select it correctly.

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 for when this tool is appropriate: arbitrary shell access on the host machine, with a strong warning to treat it as shell access. It does not explicitly name alternatives or exclusions, but the 'host machine' scope and danger framing make the intended use unambiguous.

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 states that the tool clicks, specifies the default button behavior, and notes that it returns a JSON response. However, it does not mention potential side effects (e.g., whether the cursor moves, focus requirements, or if the action is blocking). For a simple click, this is adequate but not exhaustive.

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, front-loaded with the core purpose, and efficiently lists parameters and returns. It has no redundant wording and every sentence contributes to usability.

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 click operation, the description is largely complete. It specifies parameters, defaults, and return type. It does not explicitly state the coordinate system origin (though 'absolute screen coordinates' implies standard top-left), and it does not discuss error handling. Given the tool's low complexity and the presence of an output schema, this is nearly 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?

Every parameter is explicitly explained: serialno is described as coming from list_devices, x and y are specified as screen pixels, and button lists allowed values and its default. This adds meaning beyond the raw schema, which only provides types and titles. The description fully covers all parameters, compensating for any lack of schema-level 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 action ('Click') and the resource ('absolute screen coordinates'). It is distinct from sibling tools like computer_double_click and computer_move, making it immediately clear what this tool does and what it does not do.

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_double_click or computer_long_click. It does not state any prerequisites (e.g., needing an active device) or mention exclusions. The only contextual hint is 'from list_devices' for the serialno parameter, but that is not an explicit usage guideline.

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. It does clarify that the click uses the left button and is at absolute screen coordinates, and that it returns a JSON response. However, it does not mention potential side effects, coordinate origin, or multi-monitor behavior, leaving some ambiguity for a UI-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 compact and well-structured: one sentence for the action, then clear Args and Returns sections. Every line earns its place with no redundant 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 relatively simple tool, the description fully documents parameters and return type. It is missing some usage context around coordinate system details and alternatives, but the essential information for calling the tool correctly is present.

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 is the only source of parameter meaning. It adequately explains all three required parameters: serialno comes from list_devices, x is in screen pixels, and y is in screen pixels. This is clear and useful, though it could add coordinate origin or bounds details.

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

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

The description states a specific action ('Double click'), a resource ('absolute screen coordinates'), and the button ('left button'), which clearly distinguishes it from single-click or long-click siblings. It adds meaningful detail beyond the tool name.

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 guidance on when to use this tool versus alternatives like computer_click or computer_long_click. It only explains the parameters, not the selection 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 provided, the description carries the full burden of behavioral disclosure. It describes the mechanical action (press, move, release) and that it returns a JSON response, but does not mention side effects, prerequisites (e.g., device connection, permissions), whether it blocks, or error conditions. It also does not clarify if the drag triggers events or if coordinates are absolute relative to the screen origin. This is minimal behavioral information.

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 front-loaded with the core action in the first sentence. It then lists arguments and returns in a clean structure. Every sentence serves a purpose, with no filler or redundant information. The formatting is easy to parse for an agent.

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 5 required parameters and no annotations, so the description is the only source of operational context. It covers the action and parameters adequately, but omits when to use it (usage guidelines), potential error cases, and any sequence dependencies (e.g., ensuring a device is connected). Given an output schema exists, the return format is sufficiently disclosed, but overall the agent is left without enough context to decide when and how to invoke it safely beyond the basic mechanics.

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?

Given the input schema has 0% description coverage, the description effectively compensates by explaining each parameter: serialno is from list_devices, and coordinates are 'screen pixels.' It adds meaningful context beyond the bare type definitions. However, it does not specify the coordinate origin (e.g., top-left corner) or whether coordinates are relative to the primary display, which is a minor 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 the action: 'Press the left button at one point, move to another, and release.' This unambiguously describes a drag operation with a start and end point, distinguishing it from siblings like computer_click (press and release at same point), computer_move (move without pressing), and computer_scroll. The verb 'drag' is implicit but the action is specific and self-explanatory.

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. It neither mentions contexts (e.g., dragging files, windows, or selecting text) nor excludes scenarios better suited for computer_move, computer_click, or other sibling actions. An agent must infer usage purely from the tool name and action, which is insufficient.

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 behavior fully. It mentions it returns a JSON response, but doesn't discuss permissions, side effects, or how it differs from a single key press. For a hardware-triggering tool, more behavioral context is needed.

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, with a clear example up front and a short args/returns section. 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?

For a simple two-parameter tool, the description is mostly complete. It explains the parameters and return type. However, it doesn't mention potential failures, duration of key press, or modifier key specifics, which are relevant for a hotkey 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?

Schema coverage is 0%, so the description must compensate. It explains that 'serialno' comes from list_devices, and 'keys' are the keys to press together. This adds meaning beyond the schema, though it could be more detailed about key format.

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 what the tool does: 'Press keys together' with an example. It distinguishes itself from similar tools like computer_press by indicating it presses multiple keys simultaneously, though it doesn't explicitly name an alternative.

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

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

There is no explicit guidance on when to use this tool versus alternatives like computer_press or browser_hotkey. The example implies a use case, but no conditions or exclusions 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it launches an app and returns a JSON response, without mentioning side effects, whether it blocks, permissions, app-already-running behavior, or failure modes.

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, front-loaded with the core action, and uses a clear Args/Returns structure. The Returns line is somewhat boilerplate given the output schema exists, but overall it is appropriately sized and has no 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 two-parameter launch tool, this is minimally viable: it identifies both required parameters and the source of serialno. However, it leaves app_name semantics ambiguous and provides no guidance on how to resolve or specify the application, which an agent might need for a correct call.

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 adds a useful source hint for serialno ('from list_devices'), but app_name is described only as 'The application name', which is nearly tautological and leaves unclear whether it expects a display name, path, or package identifier.

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: 'Launch a desktop application.' The word 'desktop' helps distinguish it from mobile_launch_app and browser_launch, though it does not explicitly name or contrast 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?

Usage is implied by the action ('launch a desktop application') and the helpful note that serialno comes from list_devices. However, it does not explicitly state when to prefer this tool over mobile_launch_app or browser_launch, and it provides no exclusions or alternative routing.

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 burden of behavioral disclosure. It explains the press-and-hold action, the duration parameter semantics, the default behavior for duration, and the JSON return type. It does not mention pointer movement or button release, but these are minor for a simple input 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 compact, starts with a direct action sentence, and uses a clean Args list with definitions and units. No filler or redundant 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?

All required parameters are described, units are specified, the return type is noted, and an output schema exists, so nothing essential is missing. It only lacks additional context such as coordinate origin or behavior on invalid coordinates, which are minor for this 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?

Schema coverage is 0%, but the description fully compensates by explaining all four parameters: serialno's source, x/y as screen pixel coordinates, duration in seconds, and the omit-or-zero default behavior. This goes well beyond the schema titles.

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: 'Press and hold the left button at the coordinates.' This is a specific verb phrase with a clear resource and distinguishes it from computer_click, double_click, and mobile_long_press by emphasizing 'hold'.

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 like computer_click or mobile_long_press. The only contextual hint is that serialno comes from list_devices, but there are no exclusion criteria or selection 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?

No annotations are provided, so the description carries the full burden. It discloses the no-click behavior and screen-pixel units, but it omits coordinate origin, whether movement is absolute or relative, permission requirements, and any effect on the actual cursor beyond a generic 'JSON response' return note.

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-structured: a one-line purpose, a tight parameter list, and a returns line. There is no redundant or irrelevant prose.

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 all parameters are described, but the description leaves notable gaps: it does not state the coordinate origin (e.g., top-left), does not mention querying computer_screen_size for bounds, and does not address permission prerequisites or error behavior. The existing output schema mitigates the need to explain 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%, and the description compensates thoroughly: serialno is tied to list_devices, and x/y are explicitly defined as screen-pixel coordinates. This adds meaningful units and provenance that the raw schema does not provide.

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 a specific action: move the mouse without clicking. The 'without clicking' phrase helps distinguish it from click/drag siblings, but it does not explicitly name alternatives such as computer_drag or computer_position, so differentiation is partial.

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 rather than alternatives. It does not mention computer_drag, computer_scroll, computer_position, or any prerequisites beyond sourcing serialno from list_devices, leaving the selection 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?

Annotations are absent, so the description carries the full burden. It implies a read-only operation via 'Get' but does not disclose any side effects, required permissions, or potential errors. The description adds little beyond the tool's name, leaving behavior largely implicit.

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 exceptionally concise, with a one-line purpose and clear Args/Returns sections. Every sentence earns its place, and the key information is front-loaded. No waste or 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?

For a simple getter with one parameter and an output schema, the description provides the basic purpose and parameter source. It does not detail the returned envelope's structure beyond 'permission status', but the output schema likely covers that. Some context about prerequisites or error cases is missing, but overall it is 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?

The schema provides no description for the parameter (0% coverage), but the description explains serialno as the computer device serialno and directs users to list_devices as its source. This adds meaningful context beyond the schema, though it lacks format or example 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 clearly states the tool retrieves the desktop-control permission status. The verb 'Get' specifies the action, the resource is explicit, and it stands apart from sibling tools which are all action-oriented (clicks, taps, navigation). It is unambiguous and distinct.

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. It does not mention that this should be called before desktop-control actions or under what conditions. There are no sibling permission tools, so it may be self-explanatory, but the lack of explicit usage context weakens this dimension.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It does state the read-only nature via 'Get' and describes the return as a 'JSON envelope,' which is useful. It does not explicitly say the tool has no side effects or describe coordinate details, but for a simple getter the description is adequate.

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 front-loaded: the purpose is the first sentence, followed by a concise Args section and a brief Returns section. Every sentence adds necessary information with no 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 one-parameter read-only getter with an output schema, the description covers the purpose, the required parameter, and the return envelope shape. It is complete enough for an agent to invoke it correctly, though a bit more detail about the position data (e.g., coordinate system) would elevate it further.

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 description coverage, the description compensates by explaining that serialno is 'The computer device serialno, from list_devices.' This adds meaningful source and relationship information beyond the schema's bare string type, though it does not detail the exact format or validation rules.

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 opens with a specific verb and resource: 'Get the current mouse position.' This clearly distinguishes it from mutating siblings like computer_move and computer_click, which change the mouse state rather than query it.

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 phrase 'Get the current mouse position' implies when to use the tool, and the serialno note points to list_devices as a prerequisite. However, it does not explicitly contrast with alternatives such as computer_move or state when not to use it, leaving usage context only implied.

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

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

With no annotations, the description carries the burden of explaining the tool's behavior. It states the action and the return format ('JSON response from the API'), but it does not disclose side effects, permission requirements, focus requirements, or whether the press includes key release 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 minimal, front-loaded with the core action, and uses a clean Args/Returns structure. Every sentence contributes useful information, with no redundant 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?

For a simple two-parameter tool, the required inputs are fully explained and an output schema exists. However, the lack of sibling differentiation and behavioral caveats leaves some selection and safety context incomplete, especially given the large set of related computer and mobile 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 description coverage is 0%, so the description must compensate for both parameters. It does: serialno is tied to list_devices and key is explained with concrete examples like Enter or F5. This is sufficient for an agent to supply correct values.

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 and object: 'Press a single key.' The 'single key' phrasing distinguishes it from sibling concepts like computer_hotkey or computer_type_text, though it does not explicitly name 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?

No guidance is given for when to choose this tool over siblings like computer_hotkey or computer_type_text. The only contextual hint is that serialno comes from list_devices, but there is no when-to-use or when-not-to-use explanation.

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 burden. It discloses that the tool returns a JSON envelope whose data carries the screen size, and that it requires a serialno from list_devices. It does not mention whether this is a read-only operation, but 'Get' implies it. It could add more context about units or coordinate system, but the core behavior is reasonably transparent.

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 front-loaded: the first sentence states the purpose, the second gives the use case, and the Args/Returns sections are minimal and useful. Every sentence earns its place with no 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?

The tool has one required parameter, no annotations, and an output schema. The description explains the parameter source, the return envelope, and the intended use case. It could mention units or coordinate system details, but for a simple getter with one param, it is nearly 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%, so the description must compensate. It explains that serialno is 'the computer device serialno, from list_devices,' which adds meaning beyond the schema's bare 'Serialno' title. However, it doesn't elaborate on how to obtain it beyond referencing list_devices, which is sufficient for a single 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 and resource: 'Get the primary screen size.' It also explains the purpose: converting coordinates returned by a vision model before calling computer_click. This clearly distinguishes it from sibling tools like computer_position or 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 gives explicit context for when to use the tool: before calling computer_click, to convert vision-model coordinates. It does not explicitly name alternatives or exclusions, but the use case is clear enough for an agent to select it appropriately.

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 burden. It discloses that amount can be omitted or 0 for driver default, and that it returns a JSON response. However, it doesn't disclose whether scrolling is relative to current position, whether it requires permissions, or what happens on invalid direction values.

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 front-loaded with the core action. The Args section is clear and each parameter gets a one-line explanation. The Returns line is minimal but sufficient. 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 3-parameter tool with an output schema, the description covers the essentials. It lacks edge-case behavior (e.g., what if direction is invalid, what if serialno is wrong) and doesn't mention any prerequisites beyond serialno from list_devices. Given the tool's simplicity, this is adequate but not rich.

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 does: it explains serialno comes from list_devices, direction is one of up/down/left/right, and amount is wheel steps with a default behavior. This adds 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 states a specific verb and resource: 'Scroll the mouse wheel' on a computer device. It distinguishes itself from siblings like computer_move and computer_click by focusing on wheel scrolling, though it doesn't explicitly name a sibling alternative.

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's for scrolling a mouse wheel on a computer device, with serialno from list_devices. It doesn't explicitly state when to use this over alternatives like computer_move or mobile_swipe, but the 'from list_devices' hint gives some 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 full responsibility for disclosing behavior. It does mention that text goes to the current caret of the focused app, which is useful, but it omits details like whether existing text is replaced, how special characters or newlines are handled, or whether focus is 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?

The description is short, front-loaded with the core action, and organized into Args and Returns sections. It wastes little space, though it could include more behavioral context without becoming bloated.

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 gives enough information to invoke the tool: both parameters are named and partially explained, and the output schema covers the return value. However, it lacks guidance on when to choose this tool over siblings and does not mention important behavioral constraints, leaving it only minimally 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%, so the description must add meaning. It does explain serialno as coming from list_devices, which is valuable, but the description of text ('The text to type') mostly restates the parameter name. Overall it partially compensates 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 clearly states the action: type text at the current caret of the focused app. It is specific about the verb and resource, but it does not explicitly differentiate itself from similar siblings like mobile_input_text or computer_bash.

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 mobile_input_text for mobile devices or computer_bash for shell input. The description implies usage context through 'focused app' but provides no explicit when-to-use 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?

No annotations are provided, so the description carries the burden. It discloses the blocking behavior, the unit, and the valid range (1-300000), and notes the return is a JSON response. It doesn't mention whether the call is synchronous, whether it can be interrupted, or any side effects, but for a simple wait operation the disclosed details are reasonably sufficient.

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 front-loaded: the purpose appears in the first sentence, and the parameter details are organized in a short Args list. Every sentence earns its place, and the unit warning is a valuable addition without bloat.

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 wait tool with an output schema, the description covers the essential semantics: what it does, the unit, the range, and the source of serialno. It could mention whether the wait is blocking or how the response is structured, but the output schema exists and the tool is simple enough that the description is nearly 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%, so the description must compensate. It explains serialno as coming from list_devices and milliseconds as the block duration in milliseconds with a range. This adds meaning beyond the bare schema types, though it doesn't describe the exact format of the JSON response.

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 ('Block') and resource ('for a duration'), and clarifies its purpose as a pacing mechanism between script steps. It is distinguishable from siblings like computer_bash or mobile_bash, though it doesn't explicitly name a sibling alternative.

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: 'useful between steps in a script' and explicitly contrasts the milliseconds unit with computer_bash's timeout in seconds. It doesn't enumerate when not to use it, but the usage context is clear enough for an agent to select it appropriately.

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 discloses the return format (JSON envelope with data array and specific fields), the semantics of the type parameter (system types match os_type because a device row only carries the coarse type), and the keyword search behavior. This is rich, actionable detail that goes beyond a minimal listing.

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 an opening usage hook ('Start here'), an Args section, and a Returns section. Every sentence adds value—no filler. The critical 'Start here' guidance is front-loaded, and the parameter explanations are concise yet complete. This is appropriately sized for the tool's complexity.

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 lack of annotations and the presence of an output schema (as indicated), the description covers purpose, when to use, all parameter semantics, and the return envelope shape. It also explains the platform-family nuance, which is essential for correct downstream tool use. No critical information an agent needs to call this tool correctly 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 schema provides zero description coverage for its 4 parameters, so the description must compensate entirely. It does so thoroughly: keyword (case-insensitive substring across a specific list of fields), state (busy, free, offline), type (category or system type with examples), and limit (default 10). Each parameter is given meaning beyond the bare schema definition.

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

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

The description states a specific verb ('list') and resource ('devices accessible to the current API key'). It clearly distinguishes itself from all sibling tools by positioning itself as the entry point for finding the serialno needed by every other tool, and it clarifies the platform-family scoping. This is unambiguous and specific.

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 explicitly says 'Start here: this is how you find the serialno that every other tool needs', giving clear when-to-use guidance. It also explains that a serialno is only meaningful within one platform family, which helps the agent understand the context. No alternative tools are needed for this action, so no exclusions are necessary.

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 behavioral burden. It states the action and notes a JSON response, but does not disclose potential side effects such as leaving the current app, navigating between screens, or doing nothing when already at the root.

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, front-loaded with the core action, and organized into clear Args and Returns sections. Every line earns its place without 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 one-parameter tool with an output schema, the description covers the essentials: what it does, the required argument's source, and the return type. However, it lacks usage context relative to sibling navigation tools and any behavioral caveats, leaving some ambiguity for an agent.

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 the description must compensate. It does by explaining that serialno is the mobile device serialno and telling the agent where to obtain it ('from list_devices'), which adds meaningful context beyond the schema's bare type and title.

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 ('Press the device back button') and identifies the target resource as a mobile device via the serialno parameter. It is concise and understandable, though it does not explicitly distinguish itself from the sibling tool browser_go_back.

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 only usage guidance points to obtaining serialno from list_devices. There is no explicit statement about when to use this tool versus alternatives like browser_go_back or mobile_home, nor any mention of 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?

With no annotations, the description carries full responsibility for behavior disclosure. It explicitly states that a non-zero exit code is returned in data.exitCode rather than as a tool error, which is a critical behavioral nuance. It also outlines the return envelope with exitCode, stdout, and stderr, making the tool's behavior predictable.

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-structured: a one-sentence purpose, a key behavioral note, then clearly labeled Args and Returns sections. It is front-loaded with the core purpose and avoids unnecessary filler, making it easy to scan.

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 the essential aspects: purpose, platform, exit code behavior, parameters, and return format. An output schema exists, so the description need not duplicate full return details, but it does provide a helpful summary. Minor gaps such as possible error conditions or the exact structure of the JSON envelope (beyond exitCode/stdout/stderr) are not critical given the output schema presence.

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% — the schema only gives field titles, no descriptions. The description compensates fully by explaining serialno as the device serial from list_devices and command as the shell command to run. This adds meaning that the schema entirely lacks, so a high score is warranted.

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 ('Run'), a clear resource ('shell command on the device'), and a platform restriction ('adb/hdc platforms only'). This unambiguously distinguishes it from the many other mobile_* tools that handle taps, swipes, and app interactions, so an agent can instantly tell what this tool is for.

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 platform restriction (adb/hdc only) gives some guidance on where it applies, but it does not explicitly contrast with alternative tools or state when to prefer this over others. Since the sibling list contains many specialized mobile actions, a note on when a generic shell command is needed (e.g., for operations not covered by other tools) would be clearer. The description implies usage but does not spell it out.

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 mutating action and notes that it returns a JSON response, but it does not discuss irreversibility, behavior when no field is focused, or whether clearing triggers UI events.

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 front-loaded: the action appears first, followed by a structured Args/Returns section. Every sentence earns its place and there is no filler or 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?

For a simple one-parameter tool with an output schema present, the description covers the action, target field, required device identifier, and return type. It lacks explicit when-to-use/alternative guidance and edge-case behavior, but nothing essential to a basic call 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 schema only defines serialno as a required string, while the description adds 'The mobile device serialno, from list_devices,' telling the agent exactly where to obtain the value. This fully compensates for the 0% 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 opens with 'Clear the focused text field' – a specific verb, target, and scope. It is distinct from the mobile_* input/tap siblings because it names the clear action, but it does not explicitly mention any alternative, so it stops short of full 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?

'Focused text field' implies the precondition that a field must be focused and that the tool is meant for erasing its content. However, there are no explicit exclusions or references to alternatives like mobile_input_text, so usage guidance is only implied rather than 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 carries the behavioral burden; the read-only nature is conveyed by 'Get' and the response shape is stated as a JSON envelope with app_name and package_name. It does not explicitly say there are no side effects, but for a read-only getter this is adequate.

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

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

Three short, labeled sections—purpose, args, returns—with no filler. The key action is front-loaded and 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 one-parameter getter with an output schema, the description covers purpose, parameter source, and return contents. Minor gap: it could explicitly name the sibling tools it is not, and could confirm no state change.

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 coverage is 0%, the description compensates by explaining serialno as 'The mobile device serialno, from list_devices,' which is more actionable than the schema's bare title. It does not give an example string, but the source tool is sufficient.

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 opening sentence, 'Get the app currently in the foreground,' uses a specific verb and resource and clearly distinguishes this from sibling tools like mobile_stop_current_app and mobile_launch_app. It does not restate the tool name without adding meaning.

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 a clear, immediate use case and the key prerequisite: serialno must come from list_devices. It does not explicitly point to alternatives or tell the agent when not to use it, so it misses the top tier.

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 implies a read-only operation ('Get device information') and specifies the return format as a 'JSON envelope whose data carries the device detail,' adding transparency about the response shape. It does not explicitly state 'read-only' or list side effects, but the nature of the tool is inherently safe and non-destructive, so a 4 is warranted.

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 tight and well-structured, with a clear one-line summary followed by a specific usage hint and a structured Args/Returns section. Every sentence earns its place, and the most important usage context is front-loaded. No wasted words.

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

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

Given the tool's simplicity (one parameter), the presence of an output schema, and the sibling context (many action tools but few info queries), the description is fully complete. It covers purpose, usage, parameter source, and return format, leaving nothing essential for an agent to infer.

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 does so by explaining the only parameter, serialno, as coming 'from list_devices,' which provides crucial provenance and usage guidance. This is exactly the kind of semantic enrichment needed beyond the bare schema field name.

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 ('device information'), listing the exact fields (status, hardware, OS version, screen size). It also distinguishes itself from sibling action tools by focusing on information retrieval, and gives a concrete use case (screen resolution before coordinate conversion), 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 a clear when-to-use scenario: 'Use this to learn the screen resolution before converting coordinates returned by a vision model.' This gives an agent explicit context for invoking it. However, it does not mention alternatives or when not to use it, though the sibling list suggests other tools are for actions rather than info queries, so the context is sufficient.

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?

There are no annotations, so the description carries the burden, and it does disclose the core effect (double tap) and the return type (JSON response from the API). However, it does not describe failure modes, device-state requirements, or side effects beyond the tap gesture, so transparency 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 compact and front-loaded: a one-sentence summary, followed by an Args section and a Returns section. There is no redundant or filler 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 simple three-parameter gesture tool, the description covers purpose, parameters, and return value, and an output schema is available. It is still missing practical context such as expected device state and how the API response signals success or failure, so completeness is adequate but not 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 has 0% description coverage, but the description compensates by explaining all three parameters: serialno comes from list_devices, and x/y are in device pixels. This adds meaningful semantics the schema alone does not provide.

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, 'Double tap at the given screen coordinates', with the target resource and coordinate-based input. It naturally distinguishes from sibling input tools like mobile_tap and mobile_long_press by naming a distinct gesture.

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 about when to choose this tool over sibling alternatives such as mobile_tap, mobile_long_press, or mobile_swipe. The description only tells how to perform the action, not the selection context or any 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 burden. It discloses the return format ('JSON envelope whose data.hierarchy holds the tree'), which is useful. However, it doesn't disclose whether this is a read-only operation, whether it requires the device to be awake, or any potential side effects. The return format disclosure is a positive, but behavioral context 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 concise and front-loaded. The first sentence states the purpose and use case, and the Args/Returns sections are minimal and informative. Every sentence earns its place with no 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?

Given the tool's simplicity (1 parameter, no nested objects, output schema present), the description is nearly complete. It explains the purpose, the parameter source, and the return envelope. It could mention whether the hierarchy is XML or JSON, or note that the device must be connected, but these are minor gaps for a simple read-only dump 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?

Schema description coverage is 0%, so the description must compensate. It explains that serialno is 'The mobile device serialno, from list_devices,' which adds meaning beyond the bare schema property name. However, it doesn't provide format details (e.g., how to obtain it beyond list_devices) or edge cases. The single parameter is adequately explained for basic use.

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: 'Get the UI element tree, for finding coordinates instead of guessing.' This is a specific verb ('Get') and resource ('UI element tree'), and it distinguishes itself from sibling tools like screenshot or mobile_tap by explaining its use case (finding coordinates). It could be slightly stronger by explicitly naming a sibling alternative, but the purpose is 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 implies when to use this tool: when you need coordinates for UI elements rather than guessing. It also mentions the serialno comes from list_devices, which is a useful prerequisite. However, it doesn't explicitly state when not to use it or name alternatives like screenshot for visual inspection. The guidance is adequate but not 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?

No annotations are present, so the description must carry the behavioral burden. It states the action and that it returns a JSON response, but it does not disclose side effects such as navigating away from the current app or whether the press awaits any state change. This is adequate for a simple input action 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 appropriately compact: one action sentence, a parameter explanation, and a returns note. The core purpose is front-loaded with 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?

For a single-parameter, simple action tool with an output schema, the description covers the action, the argument source, and the return type. It is complete enough to invoke correctly, though it lacks usage-selection guidance.

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%, but the description compensates by explaining that serialno is 'The mobile device serialno, from list_devices.' This adds concrete sourcing guidance beyond the bare string type in the 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 states a specific verb and resource: 'Press the device home button.' This clearly distinguishes it from sibling tools like mobile_back and mobile_tap, since it targets the home button specifically.

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 vs alternatives such as mobile_back, mobile_tap, or browser_go_back. The description only explains the action and parameters, leaving selection entirely to the agent.

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

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

No annotations are provided, so the description carries the burden. It discloses the precondition (focused field) and that it returns a JSON response, but it doesn't disclose whether the text replaces existing content, whether it supports special keys, or whether it fails if no field is focused. The behavior is partially transparent but not fully.

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-structured: a one-line summary, a precondition, an Args section, and a Returns section. Every sentence earns its place, and the most important usage constraint is front-loaded.

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 (2 params, no nested objects) and has an output schema, so the description doesn't need to explain return values. However, it lacks details about failure modes (e.g., what happens if no field is focused) and whether the text is appended or replaces existing content. For a simple input tool, this is adequate but not 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%, so the description must compensate. It does explain both parameters: serialno is 'from list_devices' and text is 'the text to type.' This adds meaning beyond the bare schema, but it's minimal—no format, encoding, or special character guidance. Baseline 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 verb and resource: 'Type text into the focused field.' It distinguishes itself from siblings like mobile_tap and mobile_clear_text by specifying that it types text into an already-focused field. It doesn't explicitly name a sibling alternative, but the scope is clear enough.

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 explicitly states a precondition: 'The device must already have a text field focused; tap it first.' This gives clear context for when to use the tool. It doesn't explicitly mention when not to use it or name alternatives, but the precondition is strong 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 carries the full burden and discloses key behavioral traits: remote path resolution, background execution, and the need to poll with mobile_install_status. It also notes the return envelope carries an install id. This goes beyond a bare 'install' statement and gives the agent essential operational 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 well-structured with a one-sentence summary, two important caveats, a compact Args section, and a Returns note. Every sentence contributes necessary information, and the most critical usage facts are front-loaded.

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 two-parameter install tool with an output schema, the description covers the essential operational details: how to identify the device, where the package path must live, the background nature, and how to follow up. It could optionally mention failure/exit behavior, but the status tool and return envelope are enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains serialno as 'the mobile device serialno, from list_devices' and app_path as 'Package path on the agent host' with a concrete example. Both parameters are fully clarified beyond the bare schema titles.

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 opens with the specific verb-resource pair, 'Install a package on the device,' which unambiguously states what the tool does. It further clarifies the asynchronous behavior and names the companion status tool, distinguishing it from mobile_install_status.

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 on how to invoke it: the path resolves on the agent host, not locally, and the install is a background task that must be polled with mobile_install_status. It does not explicit list exclusions or alternatives, but the guidance is sufficient for correct usage.

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 clearly signals a non-mutating query operation and states the return shape ('JSON envelope describing the install'). It does not detail polling semantics or error behavior for unknown install IDs, but for a status query this is reasonably transparent.

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-organized into Args and Returns sections. Every sentence contributes meaningful guidance, and there is no filler or repetition of schema titles.

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 status query with an output schema available, the description is complete. It explains what the tool does, how the parameters relate to sibling tools, and what kind of response to expect, leaving no critical gap for an agent trying 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?

Schema description coverage is 0%, so the description must compensate for both parameters. It does so fully by explaining that serialno comes from list_devices and install_id comes from mobile_install_app, giving an agent precise information about how to obtain the values.

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 ('Query') and a clear resource ('background install task started by mobile_install_app'), immediately distinguishing this status-retrieval tool from the related mobile_install_app sibling. The purpose is unambiguous and an agent can tell what this tool does without inspecting 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?

The description states that the task must have been started by mobile_install_app and gives the exact provenance of both arguments: serialno from list_devices and install_id from mobile_install_app. It does not explicitly say 'use only after mobile_install_app' or list when not to use it, but the usage context is clearly implied.

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

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

With no annotations provided, the description carries full burden. It only states 'Launch an app' and that it returns a JSON response, without disclosing side effects, prerequisites (e.g., app installed), failure modes, or whether it blocks. This is minimal disclosure for an action that mutates device state.

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 highly concise: one sentence for purpose, a clean argument list, and a returns line. Every part is useful and front-loaded, with no 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?

The tool is simple, but the description omits important context: error handling (e.g., if app not installed), whether it waits for launch completion, and prerequisites like device connectivity. The output schema exists but is not described in detail. Overall, it covers the basics but leaves gaps an agent might need.

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 compensates well: it explains serialno is the device ID from list_devices, and app_name is a package name or bundle ID per platform. This adds meaning beyond the bare parameter names in the schema, though it lacks examples or format validation.

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 ('Launch') and resource ('an app') on a device. It is unambiguous and distinguishes from sibling tools like mobile_stop_app or mobile_current_app by the core action. The parameter names are also clarified, making the purpose crystal 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 some context (serialno from list_devices, app_name format) but does not explicitly state when to use this tool vs alternatives like mobile_stop_app or mobile_current_app. There are no exclusions or conditions. The usage is implied by the action, but the guidance is not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the action and return type, but does not mention the hold duration, coordinate origin, behavior on invalid coordinates, or any side effects such as triggering a context menu. This is minimal behavioral information for a no-annotation 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 compact and well-structured: action first, then a parameter list, then return type. There is no filler or redundant explanation, making it easy for an agent to parse quickly. The optional 'Returns' line is short and consistent with the API-oriented framing.

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 already present, so the description does not need to explain return values in depth. It supplies the essential invocation details: which device, where to press, and in what units. Minor missing context such as coordinate origin and hold duration prevents a perfect score.

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, and it does for all three parameters. serialno is tied to list_devices, and x/y are explicitly specified as device pixels. This adds meaningful context the schema's bare titles do not provide, though it could clarify the coordinate origin.

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', applied to a clear resource, 'screen coordinates' on a mobile device. This inherently distinguishes it from siblings like mobile_tap, mobile_double_tap, and mobile_swipe, so an agent can identify what the tool does without needing the name alone.

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

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

There is no guidance about when to use this tool instead of mobile_tap, mobile_double_tap, or mobile_swipe. The description explains what the tool does but not the conditions or scenarios that warrant a long press, leaving the selection decision unsupported.

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 absent, so the description carries full responsibility for behavioral disclosure. It states 'Stop an app' but does not mention side effects (e.g., forceful termination, data loss), requirements (e.g., permissions), or error conditions. The return value is only 'JSON response from the API', which adds little beyond the output schema. For a mutation-like operation, 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 brief and well-organized: a one-line purpose, followed by parameter definitions and a return note. It is not overly verbose and avoids redundancy. However, it could be slightly more structured with a clearer separation of the return behavior, but it remains concise and 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?

The tool has an output schema, so return format is covered elsewhere. However, the description omits critical operational details: what happens if the app is not running, whether the stop is graceful or forced, and any prerequisites. For a two-parameter tool with no annotations, the description is adequate but not complete. The presence of the output schema lowers the bar, yet behavioral context is still missing, so a 3 is appropriate.

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 does: it explains that serialno comes from list_devices and that app_name is a package name (Android/HarmonyOS) or bundle ID (iOS). This provides meaning beyond the bare schema property names and clarifies expected value formats, which is helpful for an agent constructing arguments.

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 ('Stop an app') and identifies the resource via parameters. It is specific enough to distinguish from generic device actions, but it does not explicitly differentiate from the sibling 'mobile_stop_current_app', which stops the currently active app. The verb and resource are clear, but the lack of sibling differentiation keeps it from a 5.

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

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

No guidance is provided on when to use this tool versus alternatives like mobile_stop_current_app or mobile_launch_app. The description implies use when you have a specific app name, but it does not state exclusions or selection criteria. This is a minimal mention, leaving the agent to infer the appropriate 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the core destructive behavior (stopping the foreground app) and notes that the return is a JSON response, but it does not cover prerequisites, failure cases, or what the JSON response contains. It is not misleading, but it is thin.

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 compact: one sentence plus an Args/Returns stub with no wasted words. The primary action is front-loaded, and the parameter and return information are clearly structured.

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 command, the basic invocation is clear, but the description omits when to choose this tool over the closely related mobile_stop_app and does not address edge cases like no foreground app. The output schema mitigates the need for return details, but the tool-family context makes this only minimally 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 only provides the parameter name and type, but the description adds meaning by explaining that serialno is the mobile device serial number and where to obtain it ('from list_devices'). This meaningfully compensates for the 0% 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 states a specific action ('Stop') and a clearly targeted resource ('the app currently in the foreground'), which distinguishes it from the sibling mobile_stop_app, which would stop a named app. It does not explicitly name the alternative, but the foreground qualifier is a strong differentiator.

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 mobile_stop_app or mobile_current_app. The only hint is that serialno comes from list_devices, which is more about parameter sourcing than usage context. There is no mention of exclusions or 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 carries the full burden. It discloses the action and the coordinate unit ('device pixels'), plus the JSON return type, but does not mention swipe duration/speed, coordinate origin, or failure behavior such as an unsupported device state.

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: the action sentence comes first, followed by a compact Args block and a Returns line. Every sentence earns its place, and there is no filler, though the argument list could be formatted more cleanly.

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?