Server Quality Checklist

Tool Scores

• double_clickB
  3.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 behavioral burden. It directly discloses that two left-clicks are sent rapidly, which is meaningful beyond the tool name. It does not mention possible side effects of double-clicking, but for a low-level input tool this is reasonably transparent.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. It front-loads the action and adds the key behavioral detail 'two rapid left-clicks' without redundancy.

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

  Completeness2/5

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

  For a tool with 4 parameters, no annotations, and minimal schema descriptions, the description is too thin to fully guide an agent on optional x/y usage. The output schema covers return-value concerns, but the input semantics for coordinates and defaults are left unexplained, which is a meaningful gap for correct invocation.

  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 only 25%, with only pid documented. The description mentions 'widget' but gives no meaning for x/y, no guidance on whether they are widget-relative or screen coordinates, and no explanation of how omitted values behave. It does not compensate for the sparse schema documentation.

  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 identifies the action ('Double-click a widget') and specifies the mechanism ('Sends two rapid left-clicks'), which distinguishes it from the sibling single-click tool even without naming it. It is specific but does not explicitly call out sibling differentiation or edge cases.

  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 phrase 'Sends two rapid left-clicks' implies this tool is for double-click interactions, and the sibling list includes 'click' as an obvious alternative. However, the description does not state when to use double_click versus click, nor does it mention any exclusions or prerequisites.

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

• get_logsB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the data source ('app's Python logging system') and the included log fields. However, it does not describe ordering, truncation behavior, log retention, or whether logs are cleared between app launches.

  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 concise sentences with no filler. It front-loads the main action and then lists the returned fields, making it easy to scan and understand quickly.

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

  Completeness4/5

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

  For a read-only log retrieval tool with an output schema, the description and input schema cover the core invocation needs: what data is returned, where it comes from, and how to target a specific app via pid. The main gap is the lack of guidance on choosing this over sibling tools, which is a usage-rule gap rather than a fundamental completeness gap.

  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 50%; the pid parameter is well-documented in the schema, while n only has a default. The description adds meaning to n by saying 'last n log messages', clarifying it as a count. It does not explain edge cases like n<=0 or very large values, but overall the description and schema together give adequate parameter understanding.

  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 names a specific verb and resource: getting the last n log messages from the app's Python logging system. It also lists the contained fields (timestamp, level, logger name, message), making the tool's purpose clear. It does not explicitly name or differentiate from sibling tools like get_app_output, but the 'Python logging system' phrasing provides reasonable 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 gives no guidance about when to use this tool versus alternatives such as get_app_output or get_app_state. There are no explicit exclusions, prerequisites, or preference rules. Usage context is only implied by the tool name and description.

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

• get_widget_infoA
  3.6/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full behavioral burden. It does disclose the kind of information returned and mentions dynamic Qt properties, which is useful. However, it does not explicitly state read-only behavior, failure behavior for unknown widgets, or prerequisites like a running app.

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

  Conciseness5/5

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

  Two concise sentences with the main operation front-loaded and no filler. Every sentence adds relevant information about the tool's purpose or output scope.

  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?

  The tool is simple and output schema exists, so return-value detail is not required. Still, the description omits usage boundaries relative to many sibling tools and does not mention that widget_id likely comes from find_widget or get_widget_tree, leaving some ambiguity for an agent selecting among 21 tools.

  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 only 50%; pid is described but widget_id is not. The description adds no parameter-specific guidance and does not explain how to obtain or format widget_id, so it fails to compensate for the schema gap.

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

  Purpose5/5

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

  The description uses a specific verb-resource pair: 'Get detailed properties and state of a specific widget.' It also enumerates content areas (geometry, text, enabled/visible state, dynamic Qt properties), which clearly distinguishes it from siblings like get_widget_tree or find_widget.

  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 phrase 'specific widget' implies this tool is for inspecting one widget after its ID is known, but there is no explicit when-to-use guidance or comparison to alternatives. It does not direct the agent to find_widget for lookup or get_widget_tree for hierarchy.

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

• find_widgetA
  3.7/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 states that the tool is a read-only search returning a list of widget IDs, which is useful. It does not disclose edge behaviors such as what happens when no filters are supplied or whether the search spans the whole app tree, but it is not misleading.

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

  Conciseness5/5

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

  The description is compact: a one-sentence purpose, a one-sentence return behavior, and three concrete usage examples. Every line earns its place and the examples make invocation unambiguous.

  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?

  The tool is simple and an output schema exists, so the description does not need to detail return fields. Still, it does not explain behavior with no criteria or how multiple criteria are combined, and the absence of annotations means these gaps fall on the description.

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

  Parameters3/5

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

  Schema coverage is only 20%, but the description names the searchable criteria (class, objectName, text, visibility), which adds meaning to four parameters that lack schema descriptions. It does not explain how parameters combine (AND/OR) or clarify the pid parameter, so compensation is only partial.

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

  Purpose5/5

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

  The description uses a specific verb ('Search') and resource ('widgets') and names the filter criteria. It distinguishes itself from siblings like get_widget_tree and get_widget_info by clarifying it returns a list of matching widget IDs, which is a concrete and different outcome.

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

  Usage Guidelines3/5

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

  Usage is implied: use this tool when you need to locate widgets by class, text, object name, or visibility. However, there is no explicit guidance about when to prefer this over get_widget_tree or get_widget_info, nor any exclusions or alternatives.

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

• launch_appA
  3.7/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 behavioral burden. It discloses the key side effects — the app is spawned, the MCP bridge is injected, and the call blocks until UI readiness — but it does not disclose what happens on timeout or launch failure, whether the spawned process persists after return and requires stop_app for cleanup, or what 'UI ready' means operationally.

  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?

  A single 17-word sentence that front-loads the verb and packs in the object, the distinguishing bridge-injection side effect, and the blocking wait behavior. Every word earns its place with zero filler or repetition.

  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?

  The 100%-coverage schema and existing output schema already handle parameters and return values, so the description only needs to supply lifecycle context. It is missing sequencing guidance relative to siblings — notably that the launched app persists and should later be terminated with stop_app, and how this tool relates to the separate wait_until_ready tool given that launch_app already says it waits for readiness.

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

  Parameters3/5

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

  Schema description coverage is 100% and the parameter docs are unusually rich (absolute vs. relative path rules, examples, a deprecation notice for command, timeout tuning guidance), so the baseline of 3 applies. The tool description itself adds no parameter-level meaning beyond the schema; the 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 uses a specific verb ('Launch') and resource ('PySide6 app'), then adds two distinguishing traits: 'with the MCP bridge injected' and 'wait until the UI is ready.' This cleanly separates it from the sibling set, which contains no other launch action and instead offers complementary tools like stop_app, get_app_status, and wait_until_ready.

  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 contains no explicit when-to-use or when-not-to-use guidance and names no alternatives. Its role as the entry point in the app lifecycle is implied by the name and sibling set, and the cwd parameter description adds useful project-root context (the directory containing pyproject.toml), but the agent must infer sequencing relative to tools like get_app_status and stop_app.

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

• get_app_stateA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It implies a read-only inspection via 'Get' and states what state is returned, which gives basic transparency. However, it does not discuss freshness, error behavior, whether an app must be running, or any side effects, leaving some ambiguity for an agent invoking it.

  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 no filler. The first sentence states what the tool returns, and the second provides a focused usage scenario. Every word contributes to tool selection and invocation.

  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 simple single-parameter schema and presence of an output schema, the description is largely complete. It lacks an explicit distinction from get_app_status, but the enumerated return contents reduce confusion. For a lightweight state getter, this is adequate for correct invocation.

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

  Parameters3/5

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

  Schema coverage is 100%, so the pid parameter is already fully documented in the input schema. The description adds no additional parameter guidance, but the schema's explanation of pid, last launched app, and multi-app scenarios is sufficient. Baseline 3 applies because the description does not need to compensate.

  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 retrieves app-level state and enumerates specific contents: active window, focused widget, and screen info. This makes the resource and scope distinct enough from sibling tools. It could be improved by explicitly contrasting with get_app_status, but the verb and enumerated fields provide a clear primary purpose.

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

  Usage Guidelines4/5

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

  The description gives a concrete use case: 'Useful to understand focus before sending keyboard events.' This tells an agent when to use the tool, but it does not mention exclusions or alternatives such as get_widget_tree or get_app_status. Clear context without explicit exclusions fits the '4' level.

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

• get_app_statusA
  3.8/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 behavioral burden. It does disclose a genuinely subtle behavior — inferring modal-dialog blocking from 'process alive but bridge unresponsive' — which is valuable. However, it does not disclose edge-case behavior such as invalid pid handling, what happens when no app has been launched, or whether the bridge check times out.

  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?

  A single well-structured sentence that front-loads the core purpose ('Report combined health') and then appends a parenthetical clarification of the trickiest signal. Every clause earns its place; there is no filler or repetition of schema content.

  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?

  The tool is low-complexity (one optional, fully documented parameter) and has an output schema, so return-value documentation burden is lifted. The description covers the semantic meaning of each reported signal. The only notable gap is the lack of guidance distinguishing this from get_app_state, which keeps it from a 5.

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

  Parameters3/5

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

  Schema coverage is 100% and the pid parameter's schema description is rich ('App pid from launch_app. Omit to target the last launched app...'), so the description need not add parameter detail. It does not, but per the high-coverage baseline this is acceptable. The description adds nothing about the parameter beyond the schema, so a baseline 3 is correct.

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

  Purpose5/5

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

  The description uses a specific verb ('Report') with a concrete resource ('combined health of a launched app') and enumerates exactly what is reported: process liveness, exit code, bridge responsiveness, and modal-dialog blocking. This explicit scope clearly distinguishes it from siblings like get_logs and get_app_output by content.

  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 use case is implied by the description — it is clearly the diagnostic health-check tool — but there is no explicit when-to-use/when-not-to-use guidance. In particular, no attempt is made to differentiate it from the closely named sibling get_app_state, which could create selection ambiguity for an agent.

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

• get_launch_helpA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It clearly indicates the tool returns help text rather than performing an action, which is useful. However, it does not disclose details like whether it queries a static local file, calls an API, or what the exact help content includes.

  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?

  Very concise and front-loaded: first sentence immediately states the tool's output, second sentence gives the when-to-use guidance. No superfluous words.

  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 takes no parameters and simply returns help, the description is fairly complete. It tells the agent exactly when to invoke it. The only gap is not specifying the return format, but this is a help-returning tool, so the completeness bar is lower.

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

  Parameters4/5

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

  The tool has zero parameters and the schema already confirms that (100% coverage). The description adds value by explaining what the tool will help with (script parameter, subfolder path), which is enough for agents to know they need no additional arguments.

  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 it returns instructions on how to call launch_app, specifically covering the script parameter and subfolder path handling. It does not fully distinguish from other get_* tools, but its focus on launch_app makes its purpose recognizable.

  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 explicitly says to call this before launch_app when unsure about entry .py or subfolder path. It provides a concrete condition for use, though it does not mention when not to use it or name a direct alternative.

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

• stop_appA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It explains the default target behavior ('Omit pid to stop the last launched app'), which adds useful context, but it does not disclose side effects such as process termination consequences or what happens if no app is running.

  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 no filler. It front-loads the core purpose and immediately provides the key usage nuance about omitting pid.

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

  Completeness4/5

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

  For a simple one-parameter tool, the description covers the essential workflow and default behavior. Since an output schema exists, return values need not be described. The only minor gap is the absence of error or edge-case behavior, but overall it is sufficiently complete.

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

  Parameters3/5

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

  Schema description coverage is 100% and the pid parameter is already well-documented in the schema, including its default and when it is required. The description mostly restates the schema's guidance, so it adds little beyond the structured field definition.

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

  Purpose5/5

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

  The description clearly states the action ('Stop') and the resource ('a previously launched app'), and ties it explicitly to launch_app, which distinguishes it from the sibling tools. There is no ambiguity about what this 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 usage context: stop an app started via launch_app, and omit pid to stop the last launched app. It does not explicitly discuss when not to use it, but since no sibling tool handles stopping an app, the context is sufficient.

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

• wait_until_readyA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and it does so well: it defines 'ready' operationally, says the tool returns a readiness snapshot, and states a significant non-behavior 'does not launch anything.' It does not spell out timeout failure behavior, but the core side-effect-free waiting semantics are clear.

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

  Conciseness5/5

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

  Three sentences with no wasted wording. The readiness definition is front-loaded, followed by usage, return value, and an important exclusion. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple wait utility with an output schema, the description covers the main condition, the trigger to call it, and the return value. The only meaningful omission is the behavior/units of the timeout parameter and a direct pointer to wait_for_idle as an alternative, which would make it fully complete.

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

  Parameters3/5

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

  The schema gives a full description for pid, and the description provides meaningful semantics for quiet_ms (the quiet duration). Timeout, however, has no explanation of units or behavior, and schema coverage is only 33%, so the description does not fully compensate.

  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 names a specific operation and resource: waiting until the app UI reaches a defined ready state (visible top-level window quiet for quiet_ms). It is clear enough for an agent to know what the tool does, but it does not explicitly contrast itself with the closely named sibling wait_for_idle, so it stops short of full sibling differentiation.

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

  Usage Guidelines4/5

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

  It gives explicit guidance to use the tool after an action that reloads or rebuilds the UI and clarifies that the tool does not launch the app. It does not mention when_not to use it or directly compare with wait_for_idle, but the main usage context is unambiguous.

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

• list_actionsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It transparently indicates a read-only listing operation, scopes results to visible windows, and enumerates the reported state fields. It does not overstate or hide 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 one information-dense sentence with no filler. It front-loads the core purpose and packs the relevant scope and output details efficiently.

  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 simple optional-pid input schema, the existence of an output schema, and the straightforward read-only behavior, the description covers everything an agent needs to call the tool correctly. No critical context is missing.

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

  Parameters3/5

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

  The single parameter pid is already fully documented in the schema with 100% coverage, including its default, purpose, and when it is required. The description adds no additional parameter meaning, which is acceptable given the schema's completeness.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'List all QActions (menu items, toolbar actions) in visible windows' and specifies the returned fields (name, text, shortcut, enabled/checked state). This clearly distinguishes it from sibling tools like trigger_action, which executes actions, and get_widget_tree, which explores the widget hierarchy.

  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 the tool is for discovering available UI actions and their current state, but it does not explicitly state when to prefer it over alternatives or that trigger_action should be used to invoke actions. This is adequate but relies on inference.

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

• press_keyA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It clearly discloses the focus requirement ('currently focused widget') and enumerates supported named keys and character input. However, it does not mention what happens if no widget is focused, whether the app must be foregrounded, or how failures are surfaced.

  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 compact, front-loaded with the core operation, and then organized into a clear list of accepted keys and character input. Every sentence adds necessary information with no filler.

  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?

  The tool is simple, with two parameters and an output schema. The description covers the key format and focus precondition, while the schema covers pid. It is nearly complete for the agent to invoke correctly, though an explicit pointer to type_text for multi-character input would strengthen context.

  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 key parameter is entirely undocumented in the schema, and the description thoroughly compensates by listing all named keys and explaining single-character pass-through. The pid parameter is already well described in the schema, so combined coverage is strong.

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

  Purpose5/5

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

  The description states a specific action — 'Press a key on the currently focused widget' — which clearly identifies the tool's operation and target. It distinguishes itself from sibling tools like click, double_click, and type_text by focusing on key input rather than mouse actions or text entry.

  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 when to use this tool: when a key needs to be sent to the focused widget, rather than clicking or typing text. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.

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

• clickA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It transparently explains how coordinates are resolved in each mode: widget center, relative to widget top-left, or relative to main window. It also discloses click button options. Missing details like failure behavior or app focus are minor given the schema's pid documentation.

  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 compact and well-structured: a one-line summary followed by three bullet modes and the button option. Every sentence provides necessary semantic value, and the most important targeting rules are front-loaded.

  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?

  The tool has an output schema, so return-value details are not required. The description covers the main behavioral axes: target selection, coordinate interpretation, and button choice. One gap is that with all parameters optional, it does not state what happens if neither widget_id nor x/y is provided, but overall it is adequate for a click 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 coverage is only 20% since only pid has a description, so the description must compensate. It adds strong semantics for widget_id and x/y by explaining their interaction modes and for button by listing 'left', 'right', or 'middle'. It does not add anything beyond the schema for pid, but that parameter is already well described.

  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 opens with a specific verb and resource: 'Click a widget or screen coordinate.' The three bullets precisely differentiate coordinate modes, and the presence of 'Click' naturally distinguishes it from the sibling double_click tool even though that sibling is not named.

  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 gives clear context for how to specify a click target and includes button options, but it never states when to prefer this tool over alternatives like double_click, press_key, type_text, or scroll. Usage is implied rather than explicitly guided.

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

• eval_pythonA
  4.2/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 clearly warns that arbitrary code runs in the app, implying direct mutation and potential for damage. It also discloses the injected context variables. It doesn't mention crash risk or persistence of changes, but the arbitrary-code warning is a strong and honest disclosure.

  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 opens with the core purpose, then provides the essential context variables, compact examples, and a clear safety warning. Every line earns its place, and the structure makes the tool immediately understandable.

  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 that an output schema exists, the description does not need to explain return values. It covers the critical context availability, shows realistic usage examples, and warns about arbitrary code execution. A mention of the potential to crash the app or that the modification is in-memory would make it fully complete, but the current level is strong.

  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 50%; the required 'code' parameter has no schema description, so the tool description compensates with examples showing valid expression forms and available context objects. The 'pid' parameter is adequately documented in the schema and does not need repetition.

  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 evaluates Python expressions or executes statements inside the app process, which is a specific and distinct capability. It is easily distinguished from sibling tools like click, get_logs, or get_widget_tree, all of which are more constrained operations.

  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 warning 'use only for debugging' gives an explicit constraint on when it should be used, and the examples show practical invocation patterns. However, it does not explicitly state when to prefer sibling tools over this one or describe conditions that should rule out its use.

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

• list_appsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the output shape ('Each entry is {pid}') and the scope ('launched by this MCP server'), but doesn't mention edge cases like an empty list or whether apps are currently running. This is moderately helpful but incomplete.

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

  Conciseness5/5

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

  Two sentences with no filler; the purpose is front-loaded and the follow-up sentence adds practical guidance. Every sentence earns its place.

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

  Completeness4/5

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

  The tool is simple (no parameters, output schema exists), and the description covers what the output contains and how to use it. However, it leaves room for interpretation about the lifecycle ('launched' could mean currently running), so it's slightly under-specified.

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

  Parameters4/5

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

  The tool has zero parameters and the schema is empty, so there is nothing to explain. The description's mention of pid refers to output, not input, and is therefore not parameter documentation. Baseline 4 applies.

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

  Purpose5/5

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

  States a specific verb ('List') and resource ('apps launched by this MCP server'), making it distinct from mutation or inspection siblings. The description is unambiguous and would let an agent know exactly what this 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?

  Provides concrete context: the result of list_apps is meant to feed pid into other tools when multiple apps are running. This implies the primary use case without explicitly naming alternatives, but the guidance is clear.

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

• trigger_actionA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral context. It adds useful details: direct triggering, no menu navigation, reliability, and avoiding modal menus. However, it does not disclose potential side effects of triggering the action or behavior when both name and text are provided.

  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 no wasted words. The core behavior is front-loaded, and each sentence provides necessary information: what it does, why it is useful, and the invocation constraint.

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

  Completeness4/5

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

  For a simple three-parameter tool with an output schema, the description covers the essential invocation details: target identification and the at-least-one constraint. It could mention how to discover valid action names or what happens if no QAction matches, but those are not critical for basic correct invocation.

  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?

  Only pid has schema documentation, so the description must compensate for name and text. It does so by explaining that name is the objectName and text is the visible label, and by requiring at least one of them. It lacks details on matching semantics or precedence when both are given, but still adds significant meaning beyond the schema.

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

  Purpose5/5

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

  The description states a specific verb and resource: trigger a QAction directly, with two clear identification methods (objectName or visible label). It also distinguishes itself from menu-clicking approaches, which separates it from siblings like click and double_click.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool: avoid opening modal menus and reliably reach toolbar/menu actions. It also states the precondition 'Provide at least one of name/text.' It does not explicitly name alternative tools or exclusions, so it misses the highest bar.

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

• type_textA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the tool focuses the widget first and supports typing into the currently focused widget. However, it does not describe what happens to existing text, whether the text is inserted at the cursor, or what occurs if neither a widget_id nor a focused widget exists. This is acceptable but incomplete.

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

  Conciseness5/5

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

  Two short, front-loaded sentences carry the core behavior and the key alternative. Every word earns its place; there is no fluff or repetition of schema information.

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

  Completeness4/5

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

  For a simple 3-parameter typing tool with an output schema present, the description covers the main invocation paths: widget_id targeting and focused-widget targeting. The only real gap is the no-focus/no-widget error case, but the core operational context is otherwise sufficient.

  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 only 33%, so the description must compensate. It partially does by clarifying that widget_id can be omitted to use the focused widget and that special characters belong in press_key, not in text. However, the text parameter itself is only described by the tool name, and widget_id's relationship to other tools is left implicit.

  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 a specific action ('Type text') and a specific resource ('a widget (focuses it first) or the currently focused widget'). It also differentiates from the sibling press_key by explicitly directing special characters elsewhere, so the agent can distinguish this tool without opening schemas.

  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 gives an explicit when-not: 'For special characters use press_key instead.' This clearly routes the agent to the appropriate sibling in the common edge case, which is strong usage guidance for a text-input tool.

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

• get_widget_treeA
  4.3/5.0
  Behavior4/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 that the result is a JSON hierarchy scoped to visible windows, and enumerates the per-widget fields. It does not explicitly state that the operation is read-only, but the getter verb and output-only description make that a safe inference.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: what the tool does, what the output contains, and how to use the result. No filler or redundancy.

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

  Completeness5/5

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

  For a tool with one optional parameter and an output schema, the description plus schema fully covers invocation and expected results. The visible-window scope and field enumeration leave no significant functional 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 100%, and the pid parameter is fully described in the schema, including default behavior and when it is required. The description adds no pid-specific semantics, but the baseline of 3 is appropriate because the schema already carries that weight.

  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?

  States a specific verb and resource: 'Get the full widget hierarchy of all visible windows as JSON.' It also signals its role as the source of widget IDs for other tools, which distinguishes it from get_widget_info and find_widget.

  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?

  Provides clear context: call this tool to obtain the widget tree and use the returned IDs in other tools. It does not explicitly name alternatives or say when not to use it, but the purpose is clear enough for an agent to select it.

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

• scrollA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does disclose key behaviors: dy > 0 scrolls down, dy < 0 scrolls up, dx positive scrolls right, and omitting widget_id scrolls the main window. It lacks details like units or edge-case behavior, but the core action semantics are clearly stated.

  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 three short sentences with no filler. It front-loads the action, then efficiently explains the two scroll axes and the widget targeting behavior, with every sentence earning 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?

  The core calling details are covered, and the pid parameter is handled by the schema's own description. An output schema exists, so not describing return values is acceptable. Minor gaps remain, such as scroll units and how to obtain a valid widget_id, but these are secondary.

  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?

  Schema description coverage is only 25%, but the description compensates by explaining dy, dx, and widget_id semantics directly. The pid parameter is already well documented in the schema, so together the schema and description fully cover all four parameters.

  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 opens with 'Scroll a widget,' a specific verb and resource, and then clarifies dy/dx direction semantics. It is unambiguous and distinguishes itself from sibling tools like click, type_text, and press_key because scrolling is a distinct action.

  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 when to use the tool ('Scroll a widget') and gives targeting guidance ('omit to scroll the main window'), but it does not explicitly mention alternatives or when not to use it. There is no direct comparison to sibling tools, so usage guidance is largely implicit.

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

• screenshotA
  4.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 behavioral disclosure burden. It states that the tool returns an image, shows the current UI state, and is meant for orientation, which implies a non-destructive read operation. It could add details about failure modes or image format, but nothing in the description misleads or hides critical behavior.

  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 three short sentences with no wasted words. The core action is front-loaded, the return value is stated immediately after, and the usage tip is a natural closing. Every sentence adds value.

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

  Completeness4/5

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

  For a simple screenshot tool with no required parameters and no output schema, the description is reasonably complete: it states what is captured, what is returned, and when to call it. The remaining details, such as pid targeting behavior, are already covered by the schema. Minor omissions like error behavior keep it from a perfect score.

  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 description adds meaning to the widget_id parameter by explaining it targets 'a specific widget by ID,' which the schema does not document. The pid parameter is already well-described in the schema, including its default behavior. Together, the description and schema provide sufficient semantic coverage for both parameters.

  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 a screenshot'), the resource ('the app window' or 'a specific widget by ID'), and the return value ('the image'). This makes it easy to distinguish from sibling tools like get_widget_tree or get_widget_info, which serve different inspection purposes.

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

  Usage Guidelines4/5

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

  The description gives a clear usage directive: 'Call this first to orient yourself.' This tells the agent when to use the tool in the overall workflow. It does not explicitly discuss when not to use it or name alternative tools, but the guidance is sufficient for a straightforward screenshot tool.

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

• wait_for_idleA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and discloses the blocking condition, the quiet-window requirement, and the timeout fallback. It does not state whether timeout produces an error or a return value, but an output schema exists and the core wait semantics are transparent.

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

  Conciseness5/5

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

  Two sentences with no filler: the first defines the wait condition and the second gives the exact usage position. Every sentence earns its place and key units are front-loaded.

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

  Completeness5/5

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

  For a simple synchronization tool, this is complete: it defines what is waited on, the timeout safeguard, and the typical call context. With an output schema available, the description need not explain return values, and nothing essential for selecting or invoking the tool is missing.

  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 covers pid thoroughly, while the description adds meaning for the other two parameters by specifying quiet_ms in milliseconds and timeout in seconds. Combined, the semantics of all three parameters are recoverable, despite only 33% schema description coverage.

  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?

  States a specific behavior: wait until the app's UI has been quiet for quiet_ms ms or until timeout seconds elapse. The parenthetical 'no layout/paint activity' precisely defines idle and gives the agent a clear criterion to distinguish it from a readiness-style sibling like wait_until_ready.

  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?

  Explicitly says to call after a click or action that triggers async work and before taking a screenshot, giving the agent a clear trigger context. It does not name alternatives or state when not to use it, so it falls just short of full routing guidance.

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

• get_app_outputA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It does well by explaining that the output is actual captured console output, that launch_app redirects stdout/stderr to a log file, and that the tool only works for launch_app-started apps. It stops short of stating empty-app behavior or ordering/availability details, but the output schema likely covers return structure.

  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 concise and front-loaded with the core action. Every sentence earns its place: one defines the output, one explains the capture mechanism, one gives a debugging use case, one routes to the correct alternative, and one states the essential prerequisite.

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

  Completeness5/5

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

  For a low-complexity tool with two optional parameters and an output schema, the description provides sufficient context: what it returns, why it exists, when to use it, when to use an alternative, and the prerequisite that the app must be launch_app-managed. Nothing critical appears missing.

  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 50%, leaving n undocumented in the schema. The opening sentence compensates by defining n as the number of lines of output to retrieve. The pid parameter is thoroughly described in the schema, including its default behavior and when it is required, so the description does not need to repeat it.

  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 retrieves the last n lines of the launched app's real stdout/stderr, and enumerates what that includes: print output, tracebacks, and warnings. It also explicitly distinguishes itself from the sibling get_logs by contrasting console output with structured logging records.

  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 gives concrete when-to-use guidance: debug crashes or startup failures. It explicitly names get_logs() as the alternative for structured Python logging records, and states the important prerequisite that the app must have been started via launch_app on this server.

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