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

With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose effects (e.g., system-wide input, focus requirements), error conditions, or platform-specific behaviors, leaving significant gaps for a tool that interacts with the OS.

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

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

The description is a single, efficient sentence with no wasted words, front-loading the core action and providing illustrative examples. It's appropriately sized for a simple tool with well-defined parameters.

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

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

Given no annotations or output schema, the description is incomplete for a tool that performs system-level input. It lacks details on behavior (e.g., timing, focus dependencies), error handling, or return values, which are critical for safe and effective use in automation contexts.

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

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

Schema coverage is 100%, so the schema fully documents parameters. The description adds minimal value by hinting at key examples (e.g., 'enter', 'cmd+c'), but doesn't elaborate beyond what the schema provides, such as explaining modifier combinations or key naming conventions.

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 specific action ('press') and resource ('a key or key combination'), with examples that distinguish it from siblings like keyboard_type (typing text) or keyboard_shortcut (executing commands). It precisely defines the tool's scope without redundancy.

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 key presses via examples, but lacks explicit guidance on when to use this versus alternatives like keyboard_type for text input or mouse tools for navigation. No exclusions or prerequisites are mentioned, leaving context 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 provided, the description carries the full burden of behavioral disclosure. It mentions 'execute' but doesn't clarify what that entails—e.g., whether it simulates key presses, requires focus on a specific application, has side effects, or returns any output. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence with zero waste—it directly states the tool's action without unnecessary elaboration. It's appropriately sized and front-loaded for quick understanding.

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

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

Given the complexity of simulating keyboard shortcuts (which can have varied effects across applications) and the lack of annotations and output schema, the description is insufficient. It doesn't address behavioral nuances, return values, or error handling, making it incomplete for effective agent use.

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

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

The input schema has 100% description coverage, with the 'shortcut' parameter well-documented via an enum. The description adds no additional meaning beyond the schema, such as explaining the context or effects of each shortcut. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the verb 'execute' and the resource 'common keyboard shortcut', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'keyboard_press' or 'keyboard_type', which might handle similar keyboard interactions but in different ways.

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 like 'keyboard_press' or 'keyboard_type', nor does it specify context or prerequisites. It merely states what it does without helping the agent choose appropriately among siblings.

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

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

No annotations are provided, so the description carries full burden. It mentions the action occurs 'at current cursor position', which adds some behavioral context about targeting. However, it lacks critical details: whether this simulates keyboard events, requires focus, has side effects (e.g., triggering auto-complete), or error conditions (e.g., if no cursor exists). For a mutation tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence with zero waste. It front-loads the core action ('Type text') and adds necessary context ('at current cursor position'). Every word earns its place, 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.

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

Given the tool's complexity (a mutation action with potential side effects), no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It should explain more about how the typing works (e.g., simulated keystrokes), what happens on failure, or return values. The current description leaves too many gaps for reliable agent use.

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

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

Schema description coverage is 100% with one parameter ('text') fully documented in the schema. The description adds no parameter-specific details beyond what the schema provides (e.g., no examples, formatting rules, or constraints). With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to.

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 ('type') and resource ('text'), specifying the action occurs 'at current cursor position'. It distinguishes from siblings like keyboard_press (single key) and keyboard_shortcut (key combinations), though not explicitly named. The purpose is specific but could be more explicit about sibling differentiation.

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

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

No guidance on when to use this tool versus alternatives like keyboard_press or keyboard_shortcut. The description implies usage for typing arbitrary text at the cursor, but lacks explicit when/when-not instructions or prerequisites (e.g., requires an active text field). This leaves the agent to infer context from tool names alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't mention side effects (e.g., potential UI changes), permissions needed, or system dependencies. This is inadequate for a tool that interacts with the system at a low level.

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, clear sentence that communicates the core functionality without any wasted words. It's front-loaded and efficiently 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 system-interaction tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like what happens after the click, error conditions, or platform dependencies. The context demands more completeness than provided.

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 no parameter-specific information beyond what the schema already provides (100% coverage). It mentions 'screen coordinates' which aligns with the x and y parameters in the schema, but doesn't explain coordinate systems, units, or valid ranges. Baseline 3 is appropriate given the high schema coverage.

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

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

The description clearly states the action ('Left-click') and the target ('at screen coordinates'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like mouse_right_click or mouse_double_click, which would require 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 no guidance on when to use this tool versus alternatives like mouse_right_click, mouse_double_click, or mouse_move. It lacks any context about appropriate scenarios or exclusions, offering only basic functional information.

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 the action but doesn't cover critical aspects like whether it moves the cursor first, if it requires specific permissions, or what happens on failure (e.g., if coordinates are off-screen). This leaves significant gaps in understanding the tool's 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 extremely concise with a single, front-loaded sentence that directly states the action. There is no wasted verbiage, making it efficient 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?

Given the tool's complexity (a mouse action with coordinates), lack of annotations, no output schema, and poor parameter documentation, the description is incomplete. It doesn't address behavioral nuances, error conditions, or practical usage details needed for effective tool 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 0% description coverage for its two parameters (x and y), and the description doesn't add any semantic meaning beyond 'coordinates'. It fails to specify units (e.g., pixels), coordinate system origin, or valid ranges, which are essential for correct usage.

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

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

The description clearly states the action ('Double-click') and target ('at coordinates'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'mouse_click' or 'mouse_right_click', which would require specifying the double-click behavior more explicitly relative to single clicks.

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 'mouse_click' or 'mouse_right_click'. The description lacks context on scenarios requiring double-clicks over single clicks or other mouse actions, leaving usage unclear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Drag from point A to point B') without detailing behavioral traits such as whether it simulates a mouse button press/drag/release, the speed of the drag, error handling, or system requirements. This leaves significant gaps in understanding how the tool behaves in practice.

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 'Drag from point A to point B', which is front-loaded and wastes no words. Every part of the sentence directly contributes to understanding the tool's action, making it efficient and well-structured for its brevity.

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

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

Given the complexity of a mouse drag operation (involving UI interaction), no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't cover return values, error conditions, or practical usage details needed for an AI agent to invoke it correctly in real-world scenarios, leaving too many contextual gaps.

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

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

The input schema has 4 parameters (from_x, from_y, to_x, to_y) with 0% schema description coverage, meaning no parameter details are provided in the schema. The description adds minimal semantics by implying these are coordinates for points A and B, but it doesn't explain the coordinate system (e.g., screen pixels, relative positioning), units, or valid ranges. This fails to compensate for the low schema coverage.

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

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

The description 'Drag from point A to point B' clearly indicates the action (drag) and the resource (mouse pointer), but it's vague about the exact purpose—it doesn't specify what is being dragged (e.g., files, UI elements) or the context (e.g., desktop, application). It distinguishes from siblings like mouse_click or mouse_move by implying a continuous movement with start and end points, but lacks specificity.

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 provided on when to use this tool versus alternatives. The description implies it's for dragging operations, but it doesn't mention when to choose it over mouse_move (for simple movement) or mouse_click (for selection), nor does it specify prerequisites or exclusions. Usage is only implied by the action described.

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 burden. While 'Get' implies a read-only operation, it doesn't disclose behavioral traits such as whether this returns absolute or relative coordinates, coordinate system used, refresh rate considerations, or if it requires specific permissions. The description is too minimal for a tool with potential behavioral nuances.

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 perfectly concise at four words, front-loaded with the core action ('Get'), and contains zero wasted words. Every element earns its place in communicating the essential function.

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 (0 parameters, no output schema), the description is complete enough for basic understanding. However, without annotations or output schema, it lacks context about what exactly is returned (e.g., coordinates format, units) and how it behaves in different environments. For a tool that might have platform-specific behavior, this is insufficient.

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

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

The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters, and it correctly doesn't mention any, making it appropriately minimal in this dimension.

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

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

The description clearly states the tool's function with a specific verb ('Get') and resource ('current cursor position'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'mouse_move' or 'mouse_drag' which also relate to cursor positioning, so it doesn't reach the highest 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 description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'mouse_move' (which changes position) and 'screen_get_size' (which might provide context for positioning), there's no indication of when this read-only query is appropriate versus other mouse or screen operations.

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 but only states the basic action. It doesn't disclose behavioral traits like coordinate system (screen vs. relative), movement speed, whether it's immediate or animated, error conditions, or platform dependencies. The description is minimal but doesn't contradict any annotations.

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

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

The description is extremely concise (6 words) and front-loaded with the core action. Every word earns its place: 'Move cursor' (action), 'to position' (target), '(without clicking)' (key differentiation). No wasted verbiage.

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

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

Given no annotations, no output schema, and 2 parameters with 0% schema coverage, the description is incomplete. It covers the basic purpose but lacks essential context like coordinate system, movement behavior, error handling, or return values. For a tool that manipulates system state, this leaves significant gaps.

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

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

The schema has 0% description coverage, but the description adds minimal context by implying x and y are position coordinates. However, it doesn't specify coordinate origin, units (pixels vs. normalized), valid ranges, or interpretation. With 2 undocumented parameters, the description provides basic meaning but insufficient detail for confident usage.

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

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

The description clearly states the action ('Move cursor') and target ('to position'), with the parenthetical '(without clicking)' distinguishing it from clicking tools. However, it doesn't explicitly differentiate from mouse_drag or other movement-related siblings beyond the no-click clarification.

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 cursor positioning without activation, but provides no explicit guidance on when to choose this over mouse_drag, mouse_get_position, or other positioning alternatives. The '(without clicking)' hint suggests avoiding it when clicking is needed, but lacks comprehensive when/when-not rules.

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 but offers minimal behavioral context. It implies a GUI interaction but doesn't disclose what happens after the click (e.g., opens a context menu, requires focus), potential side effects, or system dependencies. This is inadequate for a tool that performs an action with no safety annotations.

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

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

The description is extremely concise with just three words, front-loading the core action. There is no wasted language, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.

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 action-oriented nature, no annotations, no output schema, and low parameter coverage, the description is incomplete. It lacks details on behavior, output, error conditions, and integration with sibling tools, leaving the agent with insufficient context for reliable use.

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

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

Schema description coverage is 0%, so the description must compensate but only vaguely implies parameters via 'coordinates'. It doesn't explain what x and y represent (e.g., screen pixels, relative positions), their range, or units. This leaves key semantic details undocumented.

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 'Right-click at coordinates' clearly states the action (right-click) and target (coordinates), making the purpose immediately understandable. It distinguishes from siblings like 'mouse_click' (presumably left-click) and 'mouse_double_click' by specifying the click type, though it doesn't explicitly contrast with all siblings.

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. It doesn't mention when right-clicking is appropriate compared to other mouse actions or keyboard tools, nor does it specify prerequisites like needing a visible interface or active window.

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. 'Scroll in a direction' implies a safe action but doesn't disclose behavioral traits like whether it scrolls the active window, requires focus, has rate limits, or what happens with invalid inputs. It lacks context beyond the basic action.

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

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

The description is extremely concise with a single sentence, which is front-loaded but under-specified. While efficient, it could benefit from slightly more detail to clarify scope 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?

Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what the tool returns, error conditions, or how it interacts with the system (e.g., scrolling behavior), making it inadequate for a tool with parameters and sibling tools.

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

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

Schema description coverage is 50%, with 'amount' documented but 'direction' lacking description. The description adds no meaning beyond the schema—it doesn't explain what 'direction' values mean in practice or how 'amount' translates to scroll distance. Baseline 3 is appropriate as schema covers half the parameters.

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

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

The description 'Scroll in a direction' states the basic action but is vague about the resource (mouse scrolling) and lacks specificity compared to siblings like mouse_move or mouse_drag. It distinguishes from non-scrolling siblings but doesn't clarify if it's for windows, pages, or other contexts.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention when scrolling is appropriate compared to mouse movement or keyboard shortcuts, nor does it specify any prerequisites or exclusions, leaving usage unclear.

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 adds valuable context about safety ('deletion blocked') which helps the agent understand limitations, but doesn't cover other important behavioral aspects like error handling, permissions needed, or what happens when AppleScript fails. The description provides some behavioral insight but leaves significant gaps.

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 (just 8 words) and front-loaded with the core purpose. Every word earns its place - 'Run arbitrary AppleScript code' states the action, and '(full power, deletion blocked)' adds crucial behavioral context without redundancy. This is a model of efficient description writing.

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

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

Given the tool's complexity (executing arbitrary code) and lack of both annotations and output schema, the description should do more. While it mentions safety constraints ('deletion blocked'), it doesn't explain what the tool returns, how errors are handled, or what 'full power' entails. For a code execution tool with no structured safety annotations, this is minimally adequate but leaves important 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?

With 100% schema description coverage and only one parameter, the schema already fully documents the 'script' parameter. The description doesn't add any additional parameter semantics beyond what the schema provides (type, description, requirement). This meets the baseline of 3 for high schema coverage situations.

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 specific action ('Run arbitrary AppleScript code') and the resource ('AppleScript'), distinguishing it from sibling tools like run_shell or keyboard/mouse tools. It provides a precise verb+resource combination that 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.

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

The description provides clear context about when to use this tool ('Run arbitrary AppleScript code') and implicitly distinguishes it from alternatives like run_shell (for shell commands) or other automation tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives, keeping it at a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context with 'full power, deletion blocked', hinting at capabilities and a safety restriction, but doesn't cover critical aspects like permissions, side effects, or output format, leaving gaps for a 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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's function and key behavioral note. Every word earns its place with zero waste.

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

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

Given the complexity of a shell execution tool with no annotations and no output schema, the description is incomplete. It lacks details on security implications, error handling, or return values, which are crucial for safe and effective use.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter 'command'. The description doesn't add any meaning beyond what the schema provides, such as examples or constraints, meeting the baseline for high coverage.

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

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

The description clearly states the verb ('Run') and resource ('shell command'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'run_applescript' or other execution tools, which prevents a perfect 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 description provides no guidance on when to use this tool versus alternatives like 'run_applescript' or other automation tools in the sibling list. It lacks context about appropriate scenarios or exclusions, offering minimal usage direction.

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 action ('Take a screenshot') but doesn't describe what happens after capture (e.g., where the screenshot is saved, format, permissions needed, or if it's interactive). For a tool with potential side effects and no annotation coverage, 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 extremely concise with a single, clear sentence that front-loads the core purpose. Every word earns its place, with no redundant or vague phrasing. It efficiently communicates the tool's functionality without unnecessary detail.

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

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

Given the tool's complexity (capturing screen content with potential side effects), no annotations, no output schema, and incomplete behavioral details, the description is insufficient. It doesn't cover what the tool returns, error conditions, or practical usage constraints, leaving significant gaps for an AI 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?

The schema description coverage is 100%, with the parameter 'region' documented as optional for capturing a specific area. The description adds minimal value beyond the schema by mentioning 'full screen or region', but doesn't explain coordinate systems, units, or default behavior when region is omitted. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose with a specific verb ('Take') and resource ('screenshot'), specifying it can capture full screen or region. It distinguishes from siblings like screen_get_color or screen_get_size by focusing on capture rather than measurement. However, it doesn't explicitly differentiate from all siblings (e.g., run_applescript could also capture screenshots).

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. It doesn't mention when screen_capture is preferred over other screen-related tools like screen_get_color or when to use it instead of shell commands via run_shell. There's no context about prerequisites, timing, or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify the coordinate system (e.g., screen-relative, window-relative), color format (e.g., RGB, HEX), or potential limitations (e.g., permissions needed, performance impact). For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.

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

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

The description is a single, clear sentence with no wasted words. It's front-loaded with the core action ('Get pixel color') and specifies the target ('at coordinates'), making it easy to parse quickly. Every word earns its place by directly contributing to understanding the tool's purpose.

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

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

Given the tool's moderate complexity (screen interaction with coordinates), lack of annotations, and no output schema, the description is incomplete. It doesn't cover the return value (e.g., color data format), error conditions, or practical constraints. For a tool that interacts with system-level resources, more context is needed to use it effectively and safely.

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 mentions 'coordinates' which implies the x and y parameters, but with 0% schema description coverage, it doesn't add meaningful semantics beyond what the schema already shows. It doesn't explain what x and y represent (e.g., pixel positions, units), valid ranges, or coordinate origin. The baseline is 3 because the schema covers the parameters structurally, but the description fails to compensate for the lack of semantic detail.

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 'Get' and the resource 'pixel color at coordinates', making the purpose immediately understandable. It distinguishes itself from sibling tools like screen_capture and screen_get_size by focusing on color retrieval rather than capture or dimension measurement. However, it doesn't explicitly differentiate from all siblings, keeping it from a perfect 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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., screen access permissions), typical use cases (e.g., UI testing, color sampling), or when other tools like screen_capture might be more appropriate. Without any usage context, the agent must infer when this tool is suitable.

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 what the tool does ('Get main screen dimensions') but doesn't describe how it behaves—such as whether it returns pixels, inches, or other units; if it's read-only (implied but not stated); or any performance or permission considerations. This leaves significant gaps for an agent to understand the tool's operation.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly contributing to understanding the tool's purpose.

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

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

Given the tool's simplicity (zero parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on return values (e.g., format, units) or behavioral context, which would be helpful for an agent to use it effectively. Without annotations or output schema, more completeness is needed for optimal use.

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

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

The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter information, so it meets the baseline for a parameterless tool. No additional semantic value is required or provided.

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 'Get main screen dimensions' clearly states the verb ('Get') and resource ('main screen dimensions'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'screen_capture' or 'screen_get_color' beyond the obvious difference in what's being retrieved.

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. It doesn't mention prerequisites, timing considerations, or when other tools might be more appropriate, such as using 'mouse_get_position' for coordinate-based tasks or 'window_list' for window-specific dimensions.

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 burden. 'Focus/activate' implies a UI interaction that changes application state, but it doesn't disclose behavioral traits like whether it requires specific permissions, what happens if the app isn't running, or if it's destructive (e.g., interrupting other processes). This leaves significant gaps for an agent.

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

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

The description is extremely concise ('Focus/activate an application') with zero wasted words, making it front-loaded and efficient. Every word earns its place, though this brevity contributes to gaps in other dimensions.

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

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

Given the tool's complexity (a UI interaction with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or return values, leaving the agent with insufficient information to use it reliably.

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

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

Schema description coverage is 100%, with the schema fully documenting the 'app_name' parameter. The description adds no additional meaning beyond what the schema provides, such as format examples or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('Focus/activate') and resource ('an application'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'window_list' or 'run_applescript' that might also interact with applications, so it doesn't reach the highest clarity level.

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. With siblings like 'window_list' (for listing windows), 'run_applescript' (for scripting), and 'keyboard_shortcut' (for keyboard-based activation), there's no indication of when window_focus is preferred or what prerequisites might exist.

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 burden. It states 'List all visible windows', implying a read-only operation, but doesn't disclose behavioral traits like whether it requires accessibility permissions, how it handles minimized/hidden windows, rate limits, or what the return format looks like (e.g., list of window titles, IDs). This leaves significant gaps for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool.

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

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

Given no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It lacks details on return values (critical for a 'list' operation), behavioral constraints (e.g., permissions), and how 'visible' is defined, making it inadequate for reliable agent use.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here. Baseline is 4 for zero parameters, as it avoids unnecessary 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 'List all visible windows' clearly states the action (list) and resource (visible windows). It distinguishes from siblings like window_focus or window_move by indicating a read-only enumeration rather than manipulation. However, it doesn't specify output format or scope beyond 'visible', which slightly limits 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., permissions), when-not-to-use scenarios, or comparisons to sibling tools like screen_capture or window_focus for related tasks.

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 the action ('Move') but doesn't explain what coordinate system is used (e.g., screen pixels, relative positioning), whether it requires specific permissions, potential side effects (e.g., window focus changes), or error conditions. This leaves significant gaps in understanding how the tool behaves in practice.

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

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

The description is extremely concise—a single, clear sentence that front-loads the core action. There is no wasted verbiage or redundancy, making it efficient and easy to parse. Every word earns its place, though this brevity contributes to gaps in other dimensions.

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

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

Given the tool's complexity (a mutation with 3 parameters), lack of annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain the coordinate system, error handling, or what happens if the window isn't found. For a tool that changes system state, more context is needed to use it effectively.

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 for undocumented parameters. It mentions 'position' which loosely relates to x and y, but provides no details on units, coordinate origin, or valid ranges. The app_name parameter is not addressed at all. The description adds minimal semantic value beyond what the bare schema names imply.

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

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

The description clearly states the action ('Move') and resource ('application window to position'), making the purpose immediately understandable. It distinguishes from siblings like window_focus (focusing) and window_resize (resizing), though it doesn't explicitly mention these differences. The description is specific but could be slightly more precise about what 'position' entails.

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 like window_focus or window_resize, nor does it mention prerequisites (e.g., window must be open) or context (e.g., coordinate system). It lacks explicit when/when-not instructions or named alternatives, leaving usage unclear beyond the basic action.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Resize' implies a mutation (changing window size), but the description doesn't specify whether this requires permissions, if it's reversible, what happens with invalid inputs (e.g., negative dimensions), or potential side effects (e.g., window snapping or constraints). This leaves critical behavioral traits unaddressed.

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 ('Resize application window'), which is front-loaded and wastes no words. For a simple tool, this brevity is appropriate, though it may sacrifice clarity. Every word earns its place by directly stating the core action.

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

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

Given the complexity (a mutation tool with 3 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'resize' entails (e.g., immediate effect, success/failure indicators), parameter details, or how it interacts with the system. This leaves significant gaps for an agent to understand and use the tool effectively.

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

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

The input schema has 3 parameters (app_name, width, height) with 0% description coverage, meaning none are documented in the schema. The description 'Resize application window' only implies the parameters indirectly (e.g., app_name for the window, width/height for size) but adds no explicit meaning, units (e.g., pixels), or constraints (e.g., valid ranges). This fails to compensate for the schema's lack of documentation.

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

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

The description 'Resize application window' clearly states the verb (resize) and resource (application window), making the basic purpose understandable. However, it lacks specificity about what 'application window' refers to (e.g., a specific app window vs. all windows) and doesn't differentiate from sibling tools like 'window_move' or 'window_focus', which leaves room for ambiguity.

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. It doesn't mention prerequisites (e.g., needing the app to be open), exclusions (e.g., not working with certain apps), or how it relates to siblings like 'window_move' (which might handle positioning) or 'window_list' (which could list windows). This absence of context makes it harder for an agent to choose correctly.

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