Server Quality Checklist

Tool Scores

• remote_macos_mouse_scrollC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It mentions 'automatic coordinate scaling' and environment variable usage, which adds some behavioral context. However, it lacks details on permissions, error handling, side effects, or response format, leaving significant gaps for a remote control tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action and key features. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly concise and well-structured.

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

  Completeness2/5

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

  For a remote control tool with no annotations and no output schema, the description is incomplete. It misses critical details like authentication requirements, error conditions, return values, and how scaling interacts with source dimensions. The context signals indicate moderate complexity, but the description doesn't adequately address it.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by hinting at coordinate scaling but doesn't elaborate on parameter meanings beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 ('Perform a mouse scroll'), target resource ('on a remote MacOs machine'), and key functionality ('with automatic coordinate scaling'). It distinguishes from siblings by specifying scrolling rather than clicking, moving, or other mouse actions, though it doesn't explicitly contrast with them.

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

  Usage Guidelines2/5

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

  The description mentions 'Uses environment variables for connection details,' which implies prerequisites but doesn't provide explicit guidance on when to use this tool versus alternatives like mouse_click or mouse_move. No context about appropriate scenarios or exclusions is given.

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

• remote_macos_open_applicationC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions the action ('Opens/activates') and return value ('PID for further interactions'), but lacks critical behavioral details: it doesn't specify if this requires specific permissions, whether it can open multiple instances, error handling, or platform constraints (e.g., macOS-only). For a mutation tool with zero 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action and return value. Every word earns its place with no redundancy or waste, making it highly concise and well-structured.

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

  Completeness2/5

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

  Given the complexity of a remote macOS application-opening tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, errors, or platform specifics, and lacks output details beyond mentioning PID. For a mutation tool in this context, more information is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'identifier' fully documented in the schema as 'App name, path, or bundle ID.' The description adds no additional meaning beyond this, such as examples or constraints. 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.

  Purpose4/5

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

  The description clearly states the verb ('Opens/activates') and resource ('an application'), and specifies the return value ('returns its PID for further interactions'). However, it doesn't explicitly differentiate from sibling tools like remote_macos_send_keys, which might also interact with applications. The purpose is specific but lacks sibling distinction.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., remote access to macOS), exclusions, or comparisons to sibling tools like remote_macos_send_keys for application interaction. Usage is implied by the action but not explicitly defined.

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

• remote_macos_send_keysC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions required, potential side effects (e.g., if sending keys could trigger unintended actions), error handling, or rate limits. The mention of environment variables hints at authentication needs, but this is insufficient for a mutation tool with zero 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.

  Conciseness4/5

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

  The description is concise with two sentences that directly address the tool's purpose and connection method, with no wasted words. It could be slightly improved by front-loading more critical details, but it's efficiently structured overall.

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

  Completeness2/5

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

  Given the complexity of a remote keyboard input tool (a mutation operation with potential security implications), no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits, error cases, return values, and how it integrates with sibling tools, making it inadequate for safe and effective use by an AI agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters (text, special_key, key_combination) with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, but since the schema is comprehensive, the baseline score of 3 is appropriate.

  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 ('send keyboard input') and target ('remote MacOs machine'), which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like remote_macos_open_application (which might also involve keyboard input) or explain how this differs from mouse interaction tools.

  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 mentions 'uses environment variables for connection details,' which provides some context about prerequisites, but it doesn't offer guidance on when to use this tool versus alternatives (e.g., when to send keys vs. mouse actions, or how it relates to opening applications). No explicit when/when-not rules or sibling comparisons are included.

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

• remote_macos_mouse_double_clickB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions 'automatic coordinate scaling' and environment variable usage, but lacks details on error handling, latency, permissions required, or what happens if the remote machine is unavailable. For a remote control 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.

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action, and every word earns its place—no redundancy or fluff. It efficiently conveys purpose and key constraints.

  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?

  Given 5 parameters with full schema coverage but no annotations or output schema, the description is adequate for basic understanding but lacks depth for a remote control tool. It covers the 'what' but not the 'how' or edge cases, making it minimally viable but with clear gaps in behavioral context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds value by explaining 'automatic coordinate scaling' and referencing environment variables, but doesn't provide additional semantic context beyond what's in the schema descriptions. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 ('Perform a mouse double-click'), target ('on a remote MacOs machine'), and key behavior ('with automatic coordinate scaling'). It distinguishes from sibling tools like 'remote_macos_mouse_click' by specifying double-click functionality, 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.

  Usage Guidelines2/5

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

  The description mentions 'Uses environment variables for connection details,' which implies prerequisites but doesn't provide explicit guidance on when to use this tool versus alternatives like 'remote_macos_mouse_click' or 'remote_macos_mouse_drag_n_drop.' No context on exclusions or best practices is given.

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

• remote_macos_mouse_moveB
  3.3/5.0
  Behavior2/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 mentions 'automatic coordinate scaling' and environment variable usage, but fails to address critical aspects like required permissions, potential side effects (e.g., interrupting user sessions), error conditions, or what happens if coordinates are out of bounds. This leaves significant gaps for a remote control tool.

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

  Conciseness4/5

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

  The description is efficiently structured in two sentences: the first states core functionality, the second adds implementation detail. Every element earns its place, though it could be slightly more front-loaded by mentioning environment variables earlier for immediate context awareness.

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

  Completeness2/5

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

  For a remote control tool with no annotations and no output schema, the description is insufficient. It lacks information about return values, error handling, security implications, performance characteristics, and how it integrates with sibling tools. The mention of environment variables hints at setup requirements but doesn't provide operational completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, providing complete documentation for all parameters. The description adds minimal value beyond the schema by mentioning 'automatic coordinate scaling' which relates to source_width/source_height parameters, but doesn't explain the scaling algorithm or practical implications. Baseline 3 is appropriate given the comprehensive 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 specific action ('Move the mouse cursor'), target resource ('on a remote MacOs machine'), and key functionality ('with automatic coordinate scaling'). It distinguishes itself from siblings like remote_macos_mouse_click or remote_macos_mouse_drag_n_drop by focusing solely on cursor positioning without additional actions.

  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 'Uses environment variables for connection details,' suggesting this tool requires pre-configured remote access. However, it doesn't explicitly state when to use this versus alternatives like remote_macos_mouse_drag_n_drop for dragging operations or provide clear exclusions.

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

• remote_macos_mouse_clickA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'automatic coordinate scaling' and 'environment variables for connection details', which are useful behavioral traits. However, it doesn't disclose important aspects like whether this requires specific permissions, what happens if coordinates are out of bounds, or if there are rate limits or side effects.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action and includes essential context. Every word earns its place, with no redundant or vague phrasing.

  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?

  Given no annotations and no output schema, the description is moderately complete for a 5-parameter tool. It covers the main action and scaling behavior but lacks details on error handling, return values, or prerequisites like setting environment variables. For a remote control tool with potential side effects, more behavioral context would be beneficial.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'automatic coordinate scaling', which relates to source_width/source_height parameters, but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('Perform a mouse click'), target resource ('on a remote MacOs machine'), and key behavior ('with automatic coordinate scaling'). It distinguishes itself from siblings like 'remote_macos_mouse_move' by specifying a click action rather than movement.

  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 ('remote MacOs machine', 'environment variables for connection details') but doesn't explicitly state when to use this tool versus alternatives like 'remote_macos_mouse_double_click' or 'remote_macos_mouse_drag_n_drop'. It mentions coordinate scaling but doesn't provide guidance on when to adjust source dimensions.

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

• remote_macos_mouse_drag_n_dropA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'automatic coordinate scaling' which adds useful context about coordinate transformation, but fails to describe critical behavioral aspects: whether this requires specific permissions, how errors are handled, what happens if coordinates are out of bounds, or what visual feedback occurs. For a remote control tool with 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core functionality ('Perform a mouse drag operation'), specifies the target context ('on a remote MacOs machine'), and highlights the key feature ('with automatic coordinate scaling'). Every word earns its place with zero redundancy.

  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 9-parameter remote control tool with no annotations and no output schema, the description is adequate but incomplete. It covers the basic purpose and scaling feature, but lacks information about error conditions, security requirements, visual feedback, or what constitutes successful execution. The high parameter count and remote operation context warrant more comprehensive guidance.

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

  Parameters3/5

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

  Schema description coverage is 100%, providing complete parameter documentation. The description adds minimal value beyond the schema by mentioning 'automatic coordinate scaling' which relates to the source_width/source_height parameters, but doesn't explain the scaling algorithm or provide additional parameter context. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('Perform a mouse drag operation'), target resource ('on a remote MacOs machine'), and unique feature ('with automatic coordinate scaling'). It distinguishes itself from sibling tools like 'remote_macos_mouse_move' by specifying drag-and-drop functionality rather than simple movement or clicking.

  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 'automatic coordinate scaling' and the remote MacOS focus, but provides no explicit guidance on when to use this tool versus alternatives like 'remote_macos_mouse_move' or 'remote_macos_mouse_click'. No prerequisites, exclusions, or comparison to siblings are mentioned.

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

• remote_macos_get_screenA
  3.9/5.0
  Behavior2/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 mentions connection details via environment variables, which is useful context, but doesn't describe what happens during connection (e.g., authentication needs, potential timeouts, rate limits, or what the screenshot output looks like). For a tool with zero annotation coverage, this 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.

  Conciseness5/5

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

  The description is two sentences with zero waste: the first states the purpose clearly, and the second adds essential context about environment variables. It's appropriately sized and front-loaded with the core functionality.

  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?

  Given the tool's complexity (remote connection and screenshot capture), no annotations, no output schema, and 0 parameters, the description is minimally adequate. It covers the purpose and connection method but lacks details on behavioral aspects like error handling, output format, or prerequisites, leaving room for improvement.

  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 input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of parameters. The description adds value by explaining that connection details come from environment variables, which clarifies why no parameters are needed. This compensates appropriately for the parameter-less design.

  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 ('Connect to a remote MacOs machine and get a screenshot') and distinguishes it from sibling tools that perform mouse operations, application opening, or key sending. It identifies both the verb and resource precisely.

  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 by specifying it's for remote MacOS machines and uses environment variables for connection, but doesn't explicitly state when to use this versus alternatives or any exclusions. It provides clear context but lacks explicit guidance on alternatives.

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