Server Quality Checklist

Tool Scores

• assertElementC
  2.3/5.0
  Behavior2/5

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

  The annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a low burden for safety. However, it adds no behavioral context: it does not explain what happens on a failed assertion, whether it throws an error, how multiple filters are combined, or that it does not wait. The phrase 'presence and state' restates the title without adding depth.

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

  Conciseness2/5

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

  The description is a single sentence, which is concise, but it under-specifies a tool with 14 parameters. It is not appropriately sized; the brevity is a result of missing content rather than efficient structure, making it less helpful than a longer, more informative description.

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

  Completeness1/5

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

  Given the complexity of a 14-parameter tool with no output schema, this one-line description is grossly incomplete. It lacks information about assertion semantics, return values, failure behavior, and parameter usage, leaving the agent with insufficient context to invoke the tool correctly beyond guessing.

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

  Parameters1/5

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

  With 14 parameters and 0% schema description coverage, the description fails entirely to clarify parameter meaning. It only vaguely alludes to presence and state but gives no explanation of textContains, caseInsensitive, shouldBeEnabled, or other filters, leaving the agent unable to understand how to construct a meaningful assertion.

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

  Purpose4/5

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

  The description uses the specific verb 'assert' and identifies the resource as 'element presence and state', clearly distinguishing it from siblings like findElement (locating) and waitForElement (waiting). However, it could more explicitly define what 'state' encompasses, which prevents a perfect score.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use assertElement versus alternatives such as waitForElement or findElement. The description does not mention typical verification scenarios, exclusions, or the fact that this is an immediate (non-waiting) assertion. Usage is only implied by the tool's name.

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

• findElementC
  2.4/5.0
  Behavior2/5

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

  With readOnlyHint and openWorldHint annotations already declared, the description adds no additional behavioral context. It does not state whether the tool returns the first matching element or all matches, whether it throws on no match, or how it handles multiple criteria.

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

  Conciseness4/5

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

  The description is a single, direct sentence with no unnecessary words, making it concise. It earns its place by stating the core purpose, though it lacks detail.

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

  Completeness1/5

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

  Given the tool's complexity (12 optional parameters, no output schema) and its close relationship to siblings like waitForElement and assertElement, the description is severely under-specified. It fails to explain behavior, return values, parameters, or usage context, making it difficult for an agent to select and invoke it correctly.

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

  Parameters1/5

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

  The input schema has 12 parameters with 0% description coverage, and the description merely says 'by criteria' without explaining any parameter semantics, match types (exact vs contains), or how parameters combine. There is no compensation for the schema's lack of documentation.

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

  Purpose4/5

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

  The description uses the verb 'Find' and identifies the resource as 'UI elements', which clearly states the core function. However, it does not distinguish from sibling tools like waitForElement or assertElement, which also deal with UI element discovery and verification.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as waitForElement or inspect. The description does not mention any conditions, prerequisites, or exclusions for using findElement.

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

• keyEventC
  2.4/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds no extra behavioral context. It does not explain side effects (e.g., key event simulation), handling of invalid keyCode, or whether a device must be connected.

  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 one concise sentence with no fluff. However, it is too brief to be helpful, which reduces its effectiveness despite being structurally tight.

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

  Completeness1/5

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

  With no output schema and minimal description, the tool is severely under-specified. The agent lacks essential information about keyCode values, required serial, and potential behavior, making correct invocation unlikely.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not compensate. It ignores both parameters (keyCode and serial), giving no clue about valid values or usage. This is a critical gap for an agent.

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

  Purpose4/5

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

  The description states a specific action 'Send an Android key event' and a target 'device', making the tool's purpose clear. It implicitly distinguishes from touch-based siblings like tap/swipe by referring to key events, but it does not explicitly differentiate 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?

  No guidance is provided on when to use this tool versus alternatives such as tap or inputText. There is no mention of prerequisites like an active device or appropriate use cases.

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

• tapElementC
  2.4/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is not read-only but not destructive. The description adds the behavior of tapping the center coordinate, but does not disclose what happens if no element is found, whether it waits for the element, or if multiple matches cause an error. Beyond the annotations, the description provides minimal behavioral context.

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

  Conciseness4/5

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

  The description is a single concise sentence, front-loaded with the action. It contains no redundant words. While it is short, it is appropriately sized for a simple command, though it could have added more detail without becoming verbose.

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

  Completeness1/5

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

  Given the tool's complexity (12 parameters, multiple possible selectors, no output schema), the description is severely incomplete. It provides no information on parameter combinations, required vs optional, behavior with multiple matches, or error handling. The description is insufficient for an agent to reliably use the tool correctly beyond the simplest case.

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

  Parameters1/5

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

  With 12 parameters and 0% schema description coverage, the description must compensate by explaining how parameters are used. It does not. The description only says 'Find an element' without indicating that parameters like text, class, or resourceId are used as locators. No parameter semantics are added beyond the raw schema property names.

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

  Purpose4/5

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

  The description clearly states the tool's function: find an element and tap its center coordinate. This specifies the verb (tap), resource (element), and method (center coordinate), distinguishing it from a generic coordinate-based tap. However, it does not explicitly distinguish from the sibling tool 'tap' or mention the element-finding mechanism.

  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 on when to use this tool versus alternatives like 'tap' or 'findElement'. There is no mention of prerequisites, expected scenarios, or exclusions. The 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.

• tapC
  2.6/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the action 'tap'. While annotations indicate readOnlyHint=false and destructiveHint=false, the description does not explain side effects, whether the tap is immediate, or any required device state. The openWorldHint=true annotation suggests external effects, but the description does not elaborate.

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

  Conciseness3/5

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

  The description is extremely concise at one sentence, which is structurally clean and front-loaded. However, it is under-specified, lacking key details like coordinate system and serial semantics, so it borders on under-specification rather than pure conciseness.

  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 tool's complexity and the presence of an openWorldHint, the description is incomplete. It does not mention what happens after the tap, whether it returns anything, or how the serial parameter targets a device. The sibling tools provide context but the description itself leaves significant gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only states 'coordinates', implying x and y are coordinate values, but does not explain units, origin, or the purpose of the 'serial' parameter. This is minimal added value over the raw schema.

  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 'Tap on screen at coordinates' uses a specific verb and resource, indicating a raw coordinate-based tap. This distinguishes it from sibling tools like tapElement (which likely taps UI elements) and swipe/longPress. However, it lacks explicit mention that it's a raw screen coordinate tap, which could be clearer.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool vs alternatives. It does not mention cases like 'use when you have exact screen coordinates' or contrast with tapElement. The sibling list implies distinctions, but the description itself gives no usage context.

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

• inputTextC
  2.7/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what annotations already convey. It does not disclose whether the text replaces or appends existing content, what happens if no field is focused, or any side effects. With openWorldHint=true and readOnlyHint=false, the description should provide more clarity but remains minimal.

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

  Conciseness5/5

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

  The description is a single, tightly written sentence with no superfluous words. It is front-loaded and immediately communicates the core action, earning full marks for conciseness.

  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?

  The description is too sparse for a tool with two parameters and no output schema. It lacks information about how to prepare the field, the meaning of 'serial', and possible error conditions. Sibling tools like tapElement suggest a workflow, but the description alone does not provide enough context for correct usage.

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

  Parameters1/5

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

  With 0% schema description coverage, the description must compensate for documenting parameters, but it does not. It fails to explain the 'serial' parameter and only vaguely suggests 'text' is the content to type. No additional meaning is added beyond what the tool name implies.

  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 types text into the focused input field, identifying the specific action and resource. It implicitly differentiates from siblings like tap and keyEvent by specifying text input, but does not explicitly name an alternative, so it falls short of a 5.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites such as focusing the input field first (e.g., via tap), nor does it explain when keyEvent would be more appropriate for non-text input.

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

• longPressC
  2.8/5.0
  Behavior2/5

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

  Annotations already signal readOnlyHint=false and openWorldHint=true, but the description adds no new behavioral context—no mention of what the long press does, how the optional duration affects behavior, or any side effects. It merely restates the action without enriching the annotation information.

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

  Conciseness5/5

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

  The description is a single sentence with no filler, front-loaded with the verb and object. It is maximally concise, though this brevity contributes to incompleteness in other dimensions.

  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 and no output schema, the description is too minimal. It covers the basic action and coordinates but leaves duration and serial unexplained, and provides no information about return values, side effects, or system behavior. The overall context is insufficient for an agent to fully understand or safely invoke the tool.

  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?

  With 0% schema description coverage, the description must compensate. It implies x/y are coordinates but does not explain the serial parameter or the duration parameter (units, default, purpose). The description only weakly clarifies the meaning of the required parameters, leaving optional ones entirely ambiguous.

  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 ('press and hold') and the target ('on screen at coordinates'), which distinguishes it from tap and swipe superficially. However, it does not explicitly name sibling tools or contrast with them, so it falls short of full differentiation.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like tap or swipe. No mention of prerequisites, exclusions, or typical scenarios where long press is appropriate.

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

• openAppB
  3.1/5.0
  Behavior2/5

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

  Annotations show readOnlyHint=false and destructiveHint=false, but the description adds little beyond the basic action. It does not disclose failure modes (e.g., app not installed), side effects (e.g., app foregrounded), device selection needs, or any other behavioral traits.

  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, well-structured sentence with no wasted words. It is immediately understandable and front-loaded with the core action.

  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 tool's simplicity, the description still omits important context such as the serial parameter's role, whether the app must be pre-installed, and behavior on failure. The lack of an output schema and detailed annotations increases the need for description completeness, which is not met.

  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 coverage is 0%, so the description must clarify parameters. It explains that packageName determines which app to launch, but completely ignores the serial parameter, leaving its purpose ambiguous. This only partially compensates for the lack of schema documentation.

  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'), names the resource ('Android app'), and identifies the key parameter ('by package name'). This clearly distinguishes it from sibling tools like listPackages, installExpoGo, and tap.

  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, nor does it mention prerequisites (e.g., app must be installed) or exclusions. It is a single declarative sentence with no usage context.

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

• swipeB
  3.1/5.0
  Behavior2/5

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

  With annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds no further behavioral context. It does not explain side effects, coordinate system, duration implications, or whether the gesture blocks until completion.

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

  Conciseness5/5

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

  The description is a single sentence that is immediately front-loaded with the verb 'Swipe'. It is concise with no wasted words, earning its place by stating the core action clearly.

  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 6 parameters, no output schema, and minimal annotations, the description is inadequate. It leaves critical details about coordinate reference, duration semantics, and device targeting unspecified, making the tool difficult to use correctly without additional information.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only hints at coordinates (x1, y1, x2, y2) via 'from one coordinate to another'. It provides no meaning for the 'serial' or 'duration' parameters, nor does it clarify the expected units or coordinate space.

  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 'Swipe on screen from one coordinate to another' clearly states the action (swipe), the target (screen), and the specific nature (from one coordinate to another), which distinguishes it from sibling tools like tap and longPress that involve a single point or hold.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention appropriate scenarios (e.g., scrolling, swiping between pages) or exclusions, leaving the agent to infer usage solely from the tool name.

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

• inspectB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that it produces 'structured elements' from the UI hierarchy, which is useful context about the return value. It does not detail other behaviors (e.g., screenshot format, element filtering), but the combination is sufficient beyond the annotations.

  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, compact sentence that is front-loaded with the primary action. Every word earns its place, and there is no redundant or filler content.

  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?

  With seven optional parameters, no output schema, and no parameter descriptions, the one-sentence description is far too sparse to enable correct invocation. It lacks information about return format, defaults, or how parameters affect behavior, making it incomplete for a tool of this complexity.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation of the seven parameters (serial, maxElements, screenshotMode, etc.). Parameter names offer some hints, but the description adds zero semantic value, forcing the agent to guess or infer parameter meanings.

  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: 'Capture a screenshot and parse UI hierarchy into structured elements.' This distinguishes it from the sibling 'screenshot' tool (which likely only captures) and other UI interaction tools, making the purpose unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'screenshot' or 'findElement'. It does not mention scenarios where this tool is preferred, nor does it mention any exclusions or prerequisites, offering no usage direction.

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

• waitForElementB
  3.3/5.0
  Behavior3/5

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

  The description adds the timeout behavior to the read-only annotations, but does not disclose what happens upon timeout (e.g., error vs. false return) or whether it polls at a fixed interval. The annotations already signal safe read-only behavior, but the description provides minimal additional behavioral context.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no wasted words. While it is minimal, it effectively communicates the core action and termination condition.

  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 tool's 15 parameters, no output schema, and no parameter descriptions, the description is too sparse. It covers the basic wait behavior but omits crucial context about selector semantics, polling behavior, and return values, making it incomplete for effective use.

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

  Parameters1/5

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

  With 0% schema description coverage and 15 undocumented parameters, the description fails to explain how to specify the target element. It does not mention that selector fields like text, class, resourceId, etc., are used to identify the element, leaving parameter meaning entirely to the schema's bare type definitions.

  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 'Wait until an element appears or timeout is reached' clearly identifies the tool as a wait/synchronization operation for UI elements. It distinguishes itself from sibling tools like findElement or assertElement by emphasizing the waiting behavior and timeout.

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

  Usage Guidelines3/5

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

  No explicit usage guidance or alternative comparisons are provided. The description implies a synchronization use case but does not state when to prefer this over findElement or assertElement. This makes the usage guidelines only implicitly communicated.

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

• doctorB
  3.4/5.0
  Behavior3/5

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

  Annotations include readOnlyHint=true and openWorldHint=true, which already convey safety and openness. The description adds minimal extra context about the scope (adb availability), but no additional behavioral traits like return format or potential 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, front-loaded sentence with no filler. Every word contributes to the meaning, making it highly concise for a simple diagnostic tool.

  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 tool with no parameters and no output schema, the description is adequate but not fully complete. It doesn't explicitly state what the tool returns (e.g., list of devices, status message), which could be helpful for an agent. However, the simplicity of the tool somewhat compensates.

  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, so the baseline of 4 applies. The description does not need to explain parameters; no schema details are missing.

  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 checks adb availability and connected devices, using specific verbs and resources. However, it does not explicitly distinguish itself from the sibling tool 'devices', which likely lists connected devices, so it's slightly ambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'devices'. The description simply states what it does, without discussing context, prerequisites, or exclusions.

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

• listPackagesB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds the detail that only package names are listed (not versions or other metadata), which is useful. However, it does not disclose any additional behavioral traits such as ordering, defaults, or potential side effects beyond the read-only nature.

  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 clear sentence, front-loaded with the action and subject. There is zero redundant wording, making it maximally concise and easy to parse.

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

  Completeness3/5

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

  For a simple listing tool with annotations already covering safety, the description is minimally viable. However, it lacks essential context about the parameters (filter and serial) and any output format details. The absence of an output schema increases the burden on the description, which it does not fully meet.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description gives no explanation of the 'filter' or 'serial' parameters. The description does not compensate at all for the undocumented parameters, leaving the agent without clues about how to use them. This is a significant gap for a tool with two optional 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 'List installed package names' uses a specific verb ('List') and a clear resource ('installed package names'), precisely stating what the tool does. It also distinguishes itself from sibling tools like 'inspect' or 'openApp' by focusing on the enumeration of installed packages. No ambiguity.

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

  Usage Guidelines3/5

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

  The description implicitly indicates usage when one needs to see installed packages, but it does not provide explicit guidance on when to use this tool versus alternatives. There are no exclusions or context about the optional parameters, so the guidance is only implied rather than explicit.

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

• screenshotA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, which cover the safety profile. The description adds only that it performs no UI element parsing, a useful behavioral distinction, but it says nothing about return formats, serial handling, or path 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?

  A single, focused sentence with no fluff. It is front-loaded with the core action and immediately differentiates from siblings.

  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?

  The description is too thin to enable correct invocation: it omits param semantics, output behavior, and device targeting. With optional params and no output schema, the agent is left guessing.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description mentions none of the three parameters (mode, path, serial). With no compensation from the description, the agent has no understanding of parameter meanings or options.

  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 verb ('Capture') and resource ('a screenshot'), and the qualifier 'without UI element parsing' distinguishes it from sibling tools like inspect and findElement. This provides immediate clarity on what the tool does.

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

  Usage Guidelines4/5

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

  The phrase 'without UI element parsing' establishes when to use this tool (raw screenshot capture) and implies it's not for UI analysis. However, it doesn't explicitly name alternatives or state when not to use it, so it lacks explicit exclusion guidance.

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

• devicesA
  4.1/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds scope by specifying 'Android' and 'emulators', but does not disclose additional behavioral details like whether it starts the adb server, what the return format is, or how it enumerates devices. No contradiction with annotations.

  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, concise sentence that conveys the essential purpose without any wasted words. It is appropriately sized for a tool with no parameters.

  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 read-only listing tool with no parameters and no output schema, the description provides sufficient information for selecting and invoking the tool. It clearly states what it lists (Android devices and emulators) and is complete given the tool's simplicity.

  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, so schema coverage is trivially 100%. The description does not need to explain parameter behavior, and the baseline for no parameters is 4. No additional parameter information is required.

  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 'List connected Android devices and emulators' clearly states the action (list) and the specific resource (connected Android devices and emulators). It distinguishes itself from sibling tools like setDevice and doctor by focusing solely on enumeration.

  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 when the agent needs to discover available devices or emulators, but it does not explicitly state when to use this tool versus alternatives such as setDevice or doctor. There is no mention of exclusions or prerequisites.

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

• installExpoGoA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnly=false, so the mutating nature is known. The description adds valuable detail beyond the annotations: the specific 'adb install -r' mechanism, the pinned version behavior, and the restriction to official GitHub Expo Go release URLs. This provides users with a clearer behavioral model.

  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 only two sentences, front-loading the primary action and install method. The second sentence adds the alternative URL option concisely. There is no redundant or filler 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?

  For a relatively simple install tool, the description covers the action, method, and URL restrictions. It does not explain the 'serial' parameter or prerequisites like device selection, but the overall functionality is clear and no output schema is expected.

  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 description explains the 'url' parameter (overrides the default with an official release) and reinforces its schema description. However, it does not mention the 'serial' parameter, and the schema itself lacks a description for it, leaving that parameter under-documented at only 50% schema 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?

  The description clearly states the tool downloads and installs the pinned Expo Go APK via 'adb install -r', and it allows overriding with a URL. This distinguishes it from sibling UI automation tools like tap and swipe, making the purpose unambiguous.

  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 explains the primary use case (install the default Expo Go APK) and the alternative of passing a URL for a different official release. It does not explicitly mention when not to use it or compare to other tools, but the context is clear and no direct alternative install tool exists among siblings.

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

• setDeviceA
  4.3/5.0
  Behavior4/5

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

  Annotations indicate the tool is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds meaningful context by stating that the override is process-scoped and explaining the special 'auto' value to clear it. This goes beyond the annotations by clarifying the effect and scope of the operation without contradicting any hints.

  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 the main action stated first and the special case immediately after. Every word contributes value; there is no redundant information. This is a model of concise, well-structured documentation.

  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 one-parameter setter with no output schema and annotations covering safety, the description is complete. It explains what the tool does, the scope (MCP process), and the special value 'auto'. There are no hidden behaviors or additional required context for a basic use case.

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

  Parameters4/5

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

  The schema only defines 'serial' as a string with no description, providing 0% coverage. The description compensates by explaining the purpose of the parameter ('Override the active device serial') and the special value 'auto' that clears the override. While it does not enumerate all possible serial formats, it adds essential semantic meaning for the parameter.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Override the active device serial for this MCP process.' This specifies the verb (override), the resource (active device serial), and the scope (this MCP process). It also distinguishes itself from sibling tools that inspect or control devices by focusing on setting a process-wide context value.

  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: you would use this tool to change the device context for subsequent commands within the MCP process. It provides a specific instruction for clearing the override ('Use "auto" to clear override'), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage is inferred rather than clearly guided.

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