Server Quality Checklist

Tool Scores

• hold_keyC
  2.9/5.0
  Behavior2/5

  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 states the core action. It does not disclose whether the key is automatically released after the duration, whether multiple keys are passed in a single string, or what side effects holding may have.

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

  Conciseness4/5

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

  The description is a single concise, front-loaded sentence with no filler. It could be slightly improved by replacing 'one or more keys' with a concrete parameter example, but it is appropriately short.

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

  Completeness2/5

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

  For an unannotated tool with no output schema, the description is minimal. An agent can infer the basic action, but it is not told how to express multiple keys, what happens at the end of the duration, or how this tool relates to the sibling 'key' tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already explains 'key' and 'duration_ms'. The description's claim of 'one or more keys' adds a hint, but it conflicts with the singular 'Key name to hold' parameter, creating ambiguity rather than clarity.

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

  Purpose4/5

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

  The description identifies a concrete action—holding keys for a duration—and clearly names the resource ('keys'). It is distinct from the sibling 'key' in that it emphasizes holding rather than pressing, but it does not explicitly call out that distinction.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use hold_key instead of the sibling 'key' tool or any other alternative. The context of keyboard vs mouse actions is inferable, but the description leaves the selection criteria completely implicit.

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

• scrollC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral burden. It fails to state whether the pointer is moved to the coordinates first, how missing distance parameters behave, or whether vertical and horizontal scrolling can be combined. These are important behavioral details.

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

  Conciseness4/5

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

  The description is a single efficient sentence with no filler, and the core action is front-loaded. It is concise, though the brevity contributes to missing behavioral and usage context.

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

  Completeness2/5

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

  For a tool with no annotations, no output schema, four parameters, and many sibling tools, the one-sentence description is insufficient. The agent lacks key information about when to choose scroll, what side effects occur, and how the optional distances behave.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents x, y, vertical_distance, and horizontal_distance. The description adds little beyond the word 'coordinates', but the schema itself carries the parameter semantics.

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

  Purpose4/5

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

  The description uses a specific verb ('Scroll') with a clear object ('mouse wheel') and location ('specified coordinates'). It clearly separates the tool from click, mouse_move, and zoom siblings, though it does not 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.

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives, whether a preceding mouse_move is needed, or which sibling tools are better for related actions. The agent is left to infer usage from the single sentence.

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

• middle_clickB
  3.3/5.0
  Behavior2/5

  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 states the action but does not clarify whether the cursor is moved, how press/release events are handled, or whether system-specific middle-click side effects apply.

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

  Conciseness5/5

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

  The description is a single, direct sentence with no redundancy. Every word contributes to the meaning.

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

  Completeness3/5

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

  For a simple two-parameter primitive, the description plus the schema is minimally sufficient to invoke the tool. However, the absence of any behavioral or usage context leaves it only adequate, not fully informative.

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

  Parameters3/5

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

  The schema already describes both parameters fully with 100% coverage, including the screenshot coordinate space. The description adds no additional parameter semantics, which is acceptable but provides no extra value.

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

  Purpose5/5

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

  The description states a specific verb ('Click'), a specific resource ('middle mouse button'), and a coordinate target, making it clearly distinct from sibling tools such as left_click, right_click, and double_click.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose middle_click over alternatives, nor any context about middle-click-specific behaviors such as autoscroll or paste in some environments. Usage is only implied by the tool name and sibling list.

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

• typeB
  3.4/5.0
  Behavior3/5

  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 does disclose useful facts (text goes to the cursor and any Unicode is supported), but it doesn't mention side effects, prerequisites like a focused editable element, or behavior with special characters/newlines. The disclosure is minimal but not misleading.

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

  Conciseness5/5

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

  Two succinct sentences with no filler. The core action is front-loaded, and the Unicode statement is relevant additional information that earns its place.

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

  Completeness3/5

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

  For a one-parameter, simple tool the description covers the basic what and where, but it omits usage routing among sibling input tools and any preconditions. With no output schema, it also doesn't clarify return/error behavior, though that's minor for a fire-and-forget typing action.

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

  Parameters4/5

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

  The schema already covers the parameter fully ('Text to type'), so the baseline is 3. The description adds value by specifying that the text is inserted at the current cursor position and that arbitrary Unicode is accepted, giving the agent extra semantic understanding of the text parameter's intended use.

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

  Purpose4/5

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

  The description states a specific action ('Type text') with the target location ('at the current cursor position') and an encoding guarantee ('Works with any Unicode text'). This makes the tool's function clear and distinguishes it from siblings like key or left_click, though it doesn't name an alternative explicitly.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to choose this tool over sibling input tools such as key or hold_key. It doesn't mention any conditions, exclusions, or trade-offs, so an agent cannot infer the appropriate context for type versus key from this text.

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

• left_clickA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It accurately describes a left-button click at coordinates, which implies pointer movement and a single press/release, but it does not explicitly disclose side effects, click duration, or coordinate-space behavior. It is not misleading, only minimal.

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

  Conciseness5/5

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

  The description is one short, front-loaded sentence with no filler. It immediately communicates the core action and target, making it easy for an agent to parse quickly.

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

  Completeness4/5

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

  For a simple input action, the description plus the fully documented schema is sufficient for correct invocation. The description could explicitly say 'single click' to rule out double_click, but the sibling names and straightforward action make that gap minor.

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

  Parameters3/5

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

  Schema description coverage is 100%, so x, y, and modifiers are already well documented. The description adds nothing beyond the generic notion of coordinates, which is acceptable because the schema carries the parameter meaning.

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

  Purpose5/5

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

  The description states a specific verb ('click'), the exact resource ('left mouse button'), and the target ('specified coordinates'). This clearly distinguishes it from sibling tools like right_click, middle_click, and mouse_move, and aligns directly with 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.

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives such as double_click, left_click_drag, or mouse_move. The description only says what the action is, not when an agent should select it or when it should prefer a sibling.

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

• right_clickA
  3.6/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure, but it only states the action. It does not reveal whether the cursor is moved first, whether a context menu is expected, or what side effects the click may have.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the action and coordinates. There is no filler or redundant information.

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

  Completeness4/5

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

  For a simple two-parameter click tool, the description plus schema fully specify how to call it: action, button, coordinates, and coordinate space. Minor behavioral details like cursor movement are missing, but the core invocation is clear.

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

  Parameters3/5

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

  The schema already documents both x and y with 100% coverage, including the screenshot coordinate space. The description adds no parameter-level detail beyond this, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb ('Click') and resource ('right mouse button') at specified coordinates, making the tool's purpose unmistakable. It clearly differentiates from sibling tools like left_click, middle_click, and double_click.

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

  Usage Guidelines3/5

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

  Usage is implied by the right-button semantics, but the description gives no explicit guidance on when to prefer this over left_click, double_click, or other mouse tools. It also does not mention typical use cases such as context menus or preconditions.

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

• left_click_dragA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining the behavior. 'Click and drag' conveys the basic press-move-release action but does not explicitly mention that it uses the left button, what happens when start_coordinate is omitted, or whether the movement is smooth/instant. These are partially recoverable from the name and schema, but the description alone 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence with zero waste. Every word contributes to understanding the action and the two key coordinates involved.

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

  Completeness3/5

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

  For a simple primitive with no output schema and complete parameter descriptions, the combination is mostly adequate. However, the absence of annotations leaves behavioral details such as default start position and button specificity only implicit; an agent would benefit from an explicit note about the optional start_coordinate behavior in the main description.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters are already documented with start position and destination semantics. The description restates the start-to-destination relationship without adding new constraints, formats, or edge-case details, so it adds little beyond the schema.

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

  Purpose5/5

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

  The description states a specific action (click and drag) on the mouse, with explicit start and destination points, which clearly distinguishes it from sibling tools like left_click, mouse_move, and scroll. The phrase 'from start_coordinate to coordinate' leaves no ambiguity about 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.

  Usage Guidelines3/5

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

  There is no explicit guidance about when to use this tool versus alternatives like mouse_move or left_click; the intended usage is implied by the drag action itself. It does not name any siblings or exclusions, so an agent must rely on its own reasoning about what 'drag' means.

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

• double_clickA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It states the core action but does not disclose potential behavioral details such as whether the cursor is moved to the coordinates first or the timing of the two clicks. This is adequate for a simple operation but leaves some context unspecified.

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

  Conciseness5/5

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

  One sentence with no wasted words; the verb is front-loaded and the object and location are clear. Every word earns its place.

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

  Completeness4/5

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

  For a tool with only two fully documented parameters and no output schema, the description is concise and sufficient for correct invocation. It could mention the mouse movement behavior, but nothing critical is missing for an agent to call the tool correctly.

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

  Parameters3/5

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

  Schema coverage is 100% with x and y already described as pixel coordinates in screenshot space. The description adds no parameter semantics beyond what the schema provides, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a precise verb 'Double-click' and specifies the resource 'left mouse button at specified coordinates', clearly distinguishing it from sibling tools like left_click and right_click.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternative guidance is given; usage is only implied by the action itself. The agent must infer that double_click is for double-clicking rather than single-clicking, but the description does not discuss exclusions or alternatives.

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

• keyA
  3.8/5.0
  Behavior3/5

  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 adds useful context: '+' combines modifiers, named keys are accepted, and ctrl-shortcuts may trigger third-party global hotkeys on macOS. However, it does not disclose whether the press is a tap that auto-releases, how repeat interacts with combinations, or what happens if the target app is not focused.

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

  Conciseness5/5

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

  The description is efficiently front-loaded with the core action, then adds syntax, named-key list, and a high-value macOS caveat. Every sentence contributes information needed to call the tool correctly, with no filler or repetition.

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

  Completeness4/5

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

  Given the low complexity of a key-press tool, no output schema, and no annotations, the description covers the essential calling requirements: format, modifier combination, named keys, and platform caveat. The only noticeable gap is usage routing relative to sibling tools, but that is largely a usage-guidelines issue.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining the '+' modifier syntax, enumerating named keys, and giving concrete examples such as ctrl+c and command+shift+z. It does not elaborate on the repeat parameter beyond the schema's default, but that is a minor gap.

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

  Purpose5/5

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

  The description states a precise action and object: 'Press a key or key combination.' The key-combination syntax, named-key list, and examples make it immediately clear what this tool does and distinguish it from siblings like 'type' (text entry) and 'hold_key' (press-and-hold).

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to choose this tool over sibling tools such as type, hold_key, left_click, or scroll. It only provides in-tool syntax and a macOS preference rule; there is no exclusion or alternative routing, so an agent must infer when 'key' is appropriate.

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

• mouse_moveA
  4/5.0
  Behavior3/5

  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 plainly states the action and the absence of clicking, which is useful, but it does not mention potential side effects such as triggering hover events, whether movement is instant or animated, or any limitations on coordinate values.

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

  Conciseness5/5

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

  The description is a single sentence with no filler, and the key constraint ('without clicking') is included immediately. Every word earns its place.

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

  Completeness4/5

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

  For a simple two-parameter tool with fully documented parameters and no output schema, the description plus schema is nearly complete. It could additionally mention how hover side effects or coordinate mapping work, but those are not required for basic correct invocation.

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

  Parameters3/5

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

  Schema coverage is 100%: both x and y are already documented as pixel coordinates in the screenshot coordinate space. The description adds no parameter-specific meaning, but none is needed because the schema already gives sufficient semantic context.

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

  Purpose5/5

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

  Description uses a specific verb ('Move') with a clear resource ('mouse cursor') and target ('specified coordinates'), plus an explicit constraint ('without clicking'). This clearly distinguishes the tool from sibling click, double-click, and drag operations.

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

  Usage Guidelines4/5

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

  The phrase 'without clicking' effectively communicates that this tool is for pure cursor positioning or hover behavior, not for click-based actions. However, it does not explicitly name alternative tools such as left_click or cursor_position or state when-not-to-use conditions.

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

• request_accessA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It does disclose the key interactive trait: 'The user will approve or deny access for each app,' signaling this is a user-facing authorization step. However, it stops short of describing what happens when access is denied, whether the call is blocking, or what the return value looks like, which an agent would need to handle the denial path.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: purpose, ordering constraint, and the user-interaction expectation. The critical 'call FIRST' guidance is front-loaded immediately after the purpose statement. Zero filler or redundant restatement of the schema.

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

  Completeness4/5

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

  For a single-parameter gatekeeper tool with no output schema, the description covers the essentials: what it does, when to call it, and the user approval/denial interaction. The main gap is the absence of post-condition behavior (what the tool returns on approval vs denial and how the agent should react to a denial), which is slightly more important here because this tool is a mandatory prerequisite for all siblings.

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

  Parameters3/5

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

  Schema description coverage is 100%: the schema fully documents 'apps' as the list to request access for, including bundleId with an example and displayName. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies. No compensation needed, but none provided either.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Request permission to control specific applications.' This clearly distinguishes it from the sibling tools (type, click, scroll, etc.), which are all action tools that presuppose access; this tool is the permission-gating prerequisite. The phrase 'Call this FIRST' reinforces its distinct role.

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

  Usage Guidelines4/5

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

  The description gives explicit when-to-use guidance: 'Call this FIRST before any other computer-use tool.' This tells the agent the ordering constraint relative to the sibling set. However, it does not address the when-not-to-use case (e.g., if access was already granted) or name specific alternatives.

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

• zoomA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the disclosure burden. It states the main behavior (capturing a zoomed image) but does not disclose whether the tool returns an image, whether it moves the viewport or cursor, or how the zoom scale is determined.

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

  Conciseness5/5

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

  The definition is a single, front-loaded sentence with no filler. Every word contributes to the agent's understanding of the action and its target.

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

  Completeness4/5

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

  For a tool with only one required parameter and no nested objects, the description plus the 100%-covered schema is nearly complete. It would be slightly more complete if it stated the expected result/return value or zoom behavior explicitly, but the phrase 'zoomed-in screenshot' already implies the output.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema already explains the coordinate as the 'Center of zoom region [x, y]'. The description adds no extra semantic detail such as pixel/coordinate units or acceptable bounds, so it stays at the baseline for fully documented schemas.

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

  Purpose5/5

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

  The description uses a specific action verb ('Take a zoomed-in screenshot') and a clear resource ('area around the specified coordinate'). This distinguishes it from the sibling 'screenshot' tool by emphasizing the localized, zoomed scope.

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

  Usage Guidelines4/5

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

  The phrase 'zoomed-in screenshot ... around the specified coordinate' makes the targeted use case clear: local close-up inspection rather than a general screenshot. It does not explicitly name alternatives or list when-not-to-use conditions, so it falls just short of a 5.

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

• switch_displayA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full behavioral burden. It discloses that the switch is not immediate but affects subsequent operations, which is useful. However, it does not explain persistence, reversibility, or any side effects (e.g., whether the switch is session-wide or client-wide), leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  The description is a single, tightly worded sentence that front-loads the action and immediately states the purpose. Every word earns its place, and there is no redundancy or filler.

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

  Completeness5/5

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

  For a simple tool with one fully documented parameter and no output schema, the description covers what the tool does and what effect it has on subsequent operations. Nothing critical is missing 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.

  Parameters3/5

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

  Schema description coverage is 100% for the single parameter, so the schema already documents 'display' as a 0-based index or 'auto'. The description adds minimal semantic value beyond the schema, merely framing the parameter as the target display. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Switch'), the resource ('active display'), and the scope/effect ('for subsequent screenshots and actions'). This unambiguously differentiates it from the sibling input tools, which all perform direct actions rather than changing the target display.

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

  Usage Guidelines4/5

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

  The phrase 'for subsequent screenshots and actions' provides clear context on when to use this tool: as a setup step before operating on another display. It doesn't explicitly mention when not to use it or name alternatives, but there are no obvious alternative tools among the siblings for switching displays.

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

• cursor_positionA
  4.3/5.0
  Behavior4/5

  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 indicates a read operation, specifies the return shape ({x, y}), and defines the coordinate system (screenshot coordinates). It does not mention potential edge cases such as multi-display behavior, but this is a minor gap for such a simple read tool.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. It communicates the action, the object, and the output format in a compact and well-structured way.

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

  Completeness5/5

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

  For a zero-parameter read tool with no output schema, the description is complete: it tells the agent what the tool does, what it returns, and in what coordinate system. Nothing essential is missing to invoke it correctly.

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

  Parameters4/5

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

  The tool has 0 parameters, so the baseline is 4. There is no parameter information needed, and the description appropriately focuses on the output and coordinate system rather than nonexistent inputs.

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

  Purpose5/5

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

  The description specifies a clear verb and resource: it gets the current cursor position and states the output as {x, y} in screenshot coordinates. This distinguishes it from siblings like mouse_move, which sets the position rather than reading it.

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

  Usage Guidelines3/5

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

  The intended use is implied by the description: use this when you need to know the current cursor position. However, it does not explicitly state when to prefer this over a sibling like mouse_move, nor does it mention any exclusions or prerequisites.

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

• screenshotA
  4.5/5.0
  Behavior4/5

  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 returns a JPEG and describes the intended frequency of use, which communicates its passive/read-only nature. It does not explicitly say 'does not affect the screen,' but the semantics of taking a screenshot make this clear enough for an agent.

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

  Conciseness5/5

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

  Two short, purposeful sentences with no filler. The core action and output are front-loaded in the first sentence, and the usage guidance follows naturally. Every sentence earns its place.

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

  Completeness5/5

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

  For a zero-parameter, no-output-schema tool, the description is complete: it states what the tool does, what it returns, and how often to use it. There is no missing information that an agent would need to invoke it correctly based on the provided context.

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

  Parameters4/5

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

  The tool has zero parameters and schema coverage is effectively complete, so there is nothing for the description to add about individual arguments. The baseline for zero-parameter tools is 4, and the description does not create any confusion about inputs by omitting them.

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

  Purpose5/5

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

  The description clearly states the action ('Take a screenshot'), the resource ('current state of the screen'), and the output format ('JPEG image'). It is immediately distinguishable from the sibling tools, which are all input actions like clicks, keys, and mouse movement; this one is observational and returns visual data.

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

  Usage Guidelines4/5

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

  The description gives explicit when-to-use guidance: 'Call this frequently to observe what is on screen.' This tells the agent this is the primary observation tool in the set. It does not explicitly name when not to use it or mention alternatives, but the sibling list contains no other screen-observation tool, so this omission is minor.

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