Server Quality Checklist

Tool Scores

• mouse_dragA
  3.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 effectively describes the action and return values (action description, screen change detection, reaction time), which helps the agent understand the tool's behavior beyond basic parameters. However, it doesn't mention potential side effects like UI changes or system interactions.

  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 structured with a clear purpose statement followed by detailed return value documentation. Every sentence adds value: the first explains the action and use cases, the subsequent lines describe the output format. No wasted words.

  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 5-parameter tool with no annotations and no output schema, the description provides good behavioral context through return value documentation but completely neglects parameter explanations. The output details help compensate for missing schema, but parameter gaps remain significant.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It doesn't explain any of the 5 parameters (from_x, from_y, to_x, to_y, button) beyond what the schema provides (titles and types). The description focuses on output semantics instead, leaving parameters undocumented.

  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 clearly states the action ('Drag from one position to another') and provides specific use cases ('selecting text, moving items, or resizing'), which distinguishes it from sibling tools like mouse_click or mouse_scroll. However, it doesn't explicitly differentiate from mouse_double_click in terms of dragging vs. double-clicking behavior.

  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 description implies usage for specific actions (selecting text, moving items, resizing) but doesn't provide explicit guidance on when to use this tool versus alternatives like mouse_click for single clicks or key_press for keyboard interactions. No when-not-to-use scenarios or prerequisites are mentioned.

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

• mouse_double_clickA
  3.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes the return structure with three specific fields (action, screen_changed, reaction_time_ms), explains what screen_changed=false means ('click likely missed its target'), and specifies the detection zone (200x200 px) and timeframe (2 s). This goes beyond basic parameter documentation to reveal how the tool behaves and interprets results.

  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 perfectly structured and concise: first sentence states purpose with examples, followed by a clear bulleted list of return values with helpful explanations. Every sentence earns its place, with no wasted words or redundant information. It's front-loaded with the core functionality.

  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 tool's moderate complexity (GUI interaction with feedback), no annotations, no output schema, and 0% schema description coverage, the description does well by thoroughly documenting the return behavior and success detection logic. However, it misses some context like coordinate system explanation, error conditions, or performance characteristics. For a mouse interaction tool with rich feedback, it's mostly complete but has minor gaps.

  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 0%, so the description must compensate but provides no parameter-specific information. It doesn't explain what x/y coordinates represent (e.g., screen pixels, relative positioning), the meaning of button options, or default behaviors. The description focuses on output semantics instead, leaving parameters undocumented beyond the schema's basic structure.

  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 clearly states the tool's purpose: 'Double-click at screen coordinates' with specific examples of use cases ('opening files or selecting words'). It distinguishes from sibling tools like mouse_click (single click) and mouse_drag, but doesn't explicitly contrast with all siblings. The verb+resource combination is specific and actionable.

  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 description provides implied usage guidance through examples ('Use for opening files or selecting words'), but lacks explicit when-to-use vs. when-not-to-use instructions or named alternatives. It doesn't mention when to choose this over mouse_click or other input tools, leaving some ambiguity about optimal selection.

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

• key_typeA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden and adds valuable behavioral context: it returns standard feedback (action, screen_changed, reaction_time_ms), explains what screen_changed=false means (text field not focused), and advises retry strategy. It doesn't cover rate limits or error handling, but provides clear operational insight.

  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 front-loaded with core purpose, followed by return details and troubleshooting advice. Every sentence earns its place: no fluff, efficient structure, and appropriately sized for the tool's complexity.

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

  Completeness4/5

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

  Given 1 parameter, no annotations, and no output schema, the description provides good context: purpose, return format, and usage advice. It could mention error cases or limitations, but covers key aspects for a text-input tool. Slightly incomplete but mostly sufficient.

  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 description coverage is 0%, so the description must compensate. It doesn't explicitly mention the 'text' parameter, but implies it through 'Type text' and handling details (Unicode, newlines, tabs). This adds meaning beyond the bare schema, though not fully explicit. For 1 parameter, this is adequate.

  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 clearly states the tool's purpose: 'Type text' with specific capabilities (handles Unicode, newlines, tabs). It distinguishes from siblings like key_press (single key) and clipboard_set (copy-paste), 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.

  Usage Guidelines3/5

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

  The description implies usage context through the screen_changed feedback advice: use when a text field has focus, and click first if not. It doesn't explicitly state when to use vs. alternatives like key_press or clipboard_set, nor provide exclusions. Guidance is practical but not comprehensive.

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

• clipboard_setA
  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 of behavioral disclosure. It indicates this is a write operation ('Write text to the clipboard'), which implies mutation, but doesn't specify permissions needed, side effects, or error conditions. It adds some context about integration with key_press, but lacks details on clipboard overwriting or system dependencies.

  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 extremely concise with two sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second adds practical usage context, making every word earn 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?

  Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the action and basic usage, though it could benefit from more behavioral details like error handling or system-specific notes, preventing a perfect score.

  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 0%, so the description must compensate. It mentions 'text' implicitly but doesn't explain the parameter's purpose, constraints, or format beyond what the schema's title ('Text') provides. The description adds minimal value over the schema, meeting the baseline for low coverage without fully compensating.

  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 specific action ('Write text to the clipboard') and identifies the resource ('clipboard'), distinguishing it from sibling tools like clipboard_get (which reads) and other UI automation tools. It provides a complete verb+resource statement with no ambiguity.

  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 includes explicit guidance on when to use this tool by mentioning 'Use with key_press("ctrl+v") to paste,' which implies it's part of a workflow for pasting operations. However, it doesn't explicitly state when NOT to use it or name alternatives, keeping it from a perfect score.

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

• mouse_scrollA
  4/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 effectively describes the action (scroll at a position), constraints (max 5 steps), and return values including screen change detection and reaction time, which adds valuable context beyond basic parameters. However, it doesn't cover potential errors or side effects like out-of-bounds scrolling.

  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 appropriately sized and front-loaded, starting with the core action and key parameters. Every sentence adds value: the first defines the tool, the second explains parameters, and the third details return values, with no wasted words or redundancy.

  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 complexity (interactive UI tool), no annotations, and no output schema, the description is fairly complete. It covers the action, parameters, constraints, and return structure, but could improve by addressing error cases or integration with sibling tools like screen_shot for verification.

  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 description coverage is 0%, so the description must compensate. It adds meaning by explaining 'direction' as up/down/left/right and 'amount' as number of scroll steps with a max of 5, which clarifies beyond the schema's enum and integer types. However, it doesn't detail 'x' and 'y' parameters (e.g., coordinate system or units).

  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 tool's purpose with a specific verb ('Scroll') and resource ('at a position'), and distinguishes it from siblings like mouse_click or mouse_drag by focusing on scrolling behavior. It explicitly mentions the direction and amount parameters, making the action distinct.

  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 use this tool versus alternatives like mouse_drag or key_press for navigation, nor does it mention prerequisites such as needing a visible screen or active application. It lacks explicit when/when-not instructions or sibling comparisons.

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

• clipboard_getA
  4.2/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 discloses the read-only behavior ('Read') but doesn't mention potential limitations like platform-specific clipboard access, permissions required, or data format returned. It provides basic behavioral context but lacks depth.

  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 with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.

  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 tool's simplicity (0 parameters, no annotations, but has output schema), the description is mostly complete. It states the purpose clearly, but with no annotations and an output schema present, it could benefit from mentioning what the output contains (e.g., text format) to fully compensate for the lack of behavioral details.

  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 with 100% schema description coverage, so the schema already fully documents the absence of inputs. The description doesn't need to add parameter information, and it correctly implies no parameters are required, earning a baseline score for this scenario.

  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 specific action ('Read') and resource ('current clipboard text'), distinguishing it from sibling tools like clipboard_set. It precisely defines what the tool does without ambiguity.

  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 implies usage context (when clipboard content is needed) but doesn't explicitly state when to use it versus alternatives like screen_shot or other clipboard-related operations. It provides clear intent but lacks explicit comparison guidance.

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

• key_pressA
  4.3/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 burden. It discloses behavioral traits by specifying accepted key names, examples, and return format, but lacks details on permissions, side effects, or error handling. It adds useful context but is not comprehensive for a tool that interacts with system input.

  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 appropriately sized and front-loaded, starting with the core purpose, followed by details on accepted inputs and examples, and ending with return information. Every sentence adds value without redundancy, making it efficient and well-structured.

  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 tool's complexity (interacting with system keys) and lack of annotations or output schema, the description is mostly complete: it covers purpose, parameter semantics, and return format. However, it could improve by mentioning potential side effects or error cases, but it's sufficient for basic usage.

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

  Parameters5/5

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

  The input schema has 0% description coverage with one parameter 'keys' of type string. The description compensates fully by explaining the semantics: it defines what 'keys' means (key or combination), lists accepted friendly names, and provides examples. This adds significant value beyond the bare 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 clearly states the tool's purpose with a specific verb ('Press') and resource ('a key or key combination'), and it distinguishes from siblings like 'key_type' (which likely types text) and mouse-related tools by focusing on key presses. The description is precise 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 Guidelines4/5

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

  The description provides clear context by listing accepted friendly names and examples, which implicitly guides usage for key presses. However, it does not explicitly state when to use this tool versus alternatives like 'key_type' or other input tools, missing explicit exclusions or comparisons.

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

• app_listA
  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 effectively describes the tool's behavior: it scans .desktop entries in /usr/share/applications/, returns a list of dicts with name and exec fields, and clarifies that exec is used with app_launch(). This covers the operational scope and output format well for a read-only 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 efficiently structured with three paragraphs: purpose, usage guidelines, and return format. Each sentence adds value without redundancy. It's front-loaded with the core function and remains appropriately sized for the tool's complexity.

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

  Completeness5/5

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

  Given the tool's low complexity (0 parameters, no annotations, but has output schema), the description is complete. It explains what the tool does, when to use it, and details the return structure. Since an output schema exists, the description doesn't need to fully document return values, but it still provides helpful semantics for the fields.

  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, and schema description coverage is 100% (though empty). The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since no parameters exist, and the description focuses on the tool's function and output instead.

  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 specific action ('Return installed GUI apps') and resource (GUI apps from .desktop entries). It distinguishes itself from siblings like app_launch (which launches apps) and app_status (which checks status), establishing a unique purpose for listing applications.

  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 provides explicit guidance on when to use this tool: 'before choosing which app to use for a task, or after installing new software during the session.' This gives clear context for usage, though it doesn't explicitly state when NOT to use it or mention alternatives like app_status for checking if an app is already running.

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

• mouse_clickA
  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 effectively describes the tool's behavior: it performs a click action, monitors a 200x200 pixel zone for changes within 2 seconds, and provides feedback about success/failure through the screen_changed flag. It also explains what to do when the click misses (retry with adjusted coordinates or take new screenshot).

  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 perfectly structured and concise. It starts with the core action, provides usage guidance, then details the return structure with clear bullet points. Every sentence earns its place, and the information is front-loaded with the most important details first.

  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?

  Given the tool's complexity (interactive UI operation with feedback), no annotations, and no output schema, the description provides excellent completeness. It explains what the tool does, how to use it, what it returns, and how to interpret the results. The return value documentation compensates for the lack of output schema by clearly describing the response structure and semantics.

  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?

  With 0% schema description coverage, the description must compensate for the lack of parameter documentation. While it doesn't explicitly document individual parameters, it provides crucial semantic context about parameter usage ('Use coordinates from screen_shot() or inspect()') and the relationship between parameters and tool behavior. The description explains how the x,y parameters relate to screen coordinates and what happens when they're incorrect.

  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 specific action ('Click at screen coordinates') and distinguishes it from siblings by mentioning coordinate sources from screen_shot() or inspect(). It provides a precise verb+resource combination that differentiates it from other mouse-related tools like mouse_double_click or mouse_drag.

  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 provides clear context about when to use this tool ('Use coordinates from screen_shot() or inspect()') and implies when not to use it (when you don't have coordinates). However, it doesn't explicitly contrast with alternatives like mouse_double_click or provide specific exclusion criteria beyond the coordinate requirement.

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

• screen_shotA
  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 does well by explaining the stabilization behavior ('Wait for the page to stop moving before capturing'), timeout constraint ('max 2.5 s'), and default behavior ('full screen if omitted'). However, it doesn't mention what happens on failure or the output format beyond format options.

  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?

  Perfectly structured with a clear opening statement followed by organized parameter explanations. Every sentence adds value: the first establishes purpose, and each parameter description provides essential context without redundancy. The formatting with bullet-like indentation enhances readability.

  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 3-parameter tool with no annotations and no output schema, the description does an excellent job covering parameter semantics and basic behavior. The main gap is lack of information about what the tool returns (image data format, error conditions), which would be important given the absence of output schema.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates by explaining all three parameters: 'region' (area to capture, full screen default), 'format' (webp vs png with rationale), and 'stabilize' (behavior and use case). Each parameter gets meaningful context beyond what the bare schema provides.

  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 specific action ('Capture the screen') and distinguishes it from all sibling tools (which are about app control, clipboard, and mouse/keyboard interactions). It provides a clear verb+resource combination that is unambiguous in this context.

  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 provides clear context for when to use certain features ('useful right after navigation' for stabilize parameter), but doesn't explicitly state when to use this tool versus alternatives. Since sibling tools are all different interaction types (not alternative screenshot methods), this is reasonable, but no explicit comparison is made.

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

• app_launchA
  4.6/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 effectively describes key behaviors: the process runs in the background, stdout/stderr are captured in a specific log file path, and failure returns an error dict. However, it doesn't mention potential side effects like resource consumption or system impact, leaving some gaps.

  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 well-structured and front-loaded, starting with the core purpose. Every sentence adds value: launching details, constraints, behavioral context, return values, and error handling. There is no redundant information, 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.

  Completeness4/5

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

  Given the tool's complexity (launching GUI apps with background processes) and no annotations or output schema, the description is largely complete. It covers purpose, usage, behavior, parameters, and returns. However, it lacks details on permissions, rate limits, or system requirements, which could be relevant for a launch tool.

  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 description coverage is 0%, so the description must compensate. It adds meaning by specifying that the 'command' parameter must be an application listed by app_list(), clarifying its semantics beyond the schema's generic string type. This provides crucial context, though it doesn't detail command format or examples.

  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 specific action ('Launch a desktop GUI application') and resource ('application'), distinguishing it from siblings like app_list (which lists applications) and app_status (which checks status). It precisely defines what the tool does beyond just the name.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines: 'Only applications listed by app_list() are accepted' specifies when to use (with listed apps) and implies when not to use (with unlisted apps). It also references alternatives like app_status for checking status, clearly differentiating from sibling tools.

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

• app_statusA
  4.7/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. It discloses key behavioral traits: it checks running status, reads logs, returns specific data (pid, running, log_file, tail), and handles failures with an error dict. However, it doesn't mention potential side effects, rate limits, or authentication needs, leaving some gaps.

  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 well-structured and appropriately sized. It starts with the core purpose, provides usage constraints, details parameters with examples, and explains return values. Every sentence adds value without redundancy, and it's front-loaded with essential 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?

  Given the complexity (monitoring app status), no annotations, no output schema, and 0% schema coverage, the description is largely complete. It covers purpose, usage, parameters, and return values. However, it lacks details on error conditions beyond 'On failure,' and doesn't specify log file formats or access permissions, leaving minor gaps.

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

  Parameters5/5

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

  The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'pid' is a 'Process ID returned by ``app_launch()``' and 'lines' is the 'Number of trailing log lines to return (default 50).' This fully compensates for the schema's lack of descriptions.

  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 tool's purpose: 'Check whether a launched app is still running and read its logs.' It specifies the verb ('check' and 'read'), the resource ('launched app'), and distinguishes it from siblings like app_launch (which launches apps) and app_list (which lists apps).

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines: 'Only PIDs returned by ``app_launch()`` in this session are accepted.' This clearly states when to use (with PIDs from app_launch) and implies when not to use (with other PIDs or outside the session), differentiating it from alternatives like app_list.

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