Server Quality Checklist

Tool Scores

• glass_moveB
  3.1/5.0
  Behavior2/5

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

  The description merely restates the primary action and does not disclose side effects, event generation, timing, or prerequisites. Annotations only indicate this is not read-only and not destructive; they do not explain pointer-move 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 entire description is one precise sentence with no filler. It places the action verb first and the critical 'window-relative' qualifier prominently.

  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 two-parameter move command, the description and schema together specify the input and action. However, it omits any context about when to invoke it relative to other pointer tools, and it does not describe what happens after the move, so it is minimally adequate rather than 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 already provides 100% coverage of x and y, including window-relative semantics. The description adds no additional parameter details beyond the 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 clearly states a specific verb ('move') and resource ('pointer') with a coordinate target. It identifies the window-relative semantics, which makes it distinct from screen-based moves. It doesn't explicitly differentiate from sibling pointer tools like glass_click or glass_drag, but the action is 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?

  No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., a selected/focused window), no 'use X instead' for clicking or dragging, and no conditional context.

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

• glass_clickB
  3.3/5.0
  Behavior3/5

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

  The annotations already provide the basic safety profile (not read-only, not destructive), so the description only needs to add behavioral context. It usefully clarifies that modifiers are held during the action and that count enables multi-clicks, but it does not state what happens with out-of-window coordinates, whether the pointer moves, or whether window focus is required.

  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, tightly packed with the essential behavior and parameter hints, with the core action front-loaded. Nothing is wasted or redundant.

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

  Completeness3/5

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

  For a 5-parameter action tool with no output schema and minimal annotations, the description covers the input semantics well but leaves gaps around preconditions such as window activation or focus, and what a successful or failed click returns. It is usable but not fully self-contained.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description reinforces button, count, and modifiers, and adds the 'multi/range-select' use case for modifier combinations, but most of the parameter meaning is already documented in the 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 opening phrase 'Click at window-relative coordinates' names a specific action and resource, clearly identifying this as the coordinate-based click tool alongside siblings like glass_click_element. It is differentiated by the explicit coordinate framing, though it does not name the alternative tool directly.

  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 given on when to use this tool instead of glass_click_element, glass_drag, or glass_gesture, nor are prerequisites such as a selected or focused window mentioned. The description explains how to configure the click but not when it is the appropriate choice.

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

• glass_windowB
  3.4/5.0
  Behavior3/5

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

  Annotations (readOnlyHint: false, destructiveHint: false) already convey that the tool can mutate but is not dangerous. The description adds value by splitting behavior into mutating operations (focus, resize, move) and a read-only one (geometry). It does not, however, disclose consequences such as focus stealing, whether resize/move out-of-bound values are clamped, or whether geometry is returned in window-relative or screen coordinates beyond the x/y note in the schema.

  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 sentence with a scannable op list, no filler, and the core action is front-loaded. It earns a 4 rather than 5 because the omitted target-window context and the shorthand 'window' without a definition make the sentence slightly under-specified rather than merely concise.

  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 multi-operation tool with 5 parameters, the description plus schema covers dispatch semantics well, including per-param conditions and coordinates. But there is no output schema, and the description does not state what 'geometry' returns, which window the action applies to, or whether calls are relative to the currently active/selected window. These gaps are meaningful but partially offset by the very detailed schema.

  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 each parameter description already explains its meaning, per-op requirements, and coordinate semantics. The tool description itself adds no new semantic detail beyond naming the op values. With full schema coverage, the baseline of 3 is appropriate; 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 names concrete verbs (focus, resize, move, read geometry) against a clear resource (the window), so an agent quickly understands what the tool does. It is distinguishable from siblings like glass_select_window and glass_move because the word 'window' anchors the resource. It loses a point for not stating which window is targeted or how that target is established.

  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 'op: focus|resize|move|geometry' list implies usage dispatch, and the schema reinforces per-parameter conditions ('required there and ignored otherwise'), which is decent guidance. However, the description never says when to use this tool instead of related tools — for instance, whether the targeted window must first be selected via glass_select_window, or whether op:"move" is the right path versus the sibling glass_move. The guidance is 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.

• glass_list_windowsA
  3.6/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the readOnlyHint and openWorldHint annotations. The note that 'Window ids are not stable across calls' is a critical runtime behavior that agents must know to avoid caching issues, and it explicitly advises re-listing after window changes. This is a significant disclosure that goes 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 compact—two sentences—with the core action and return format first, followed by the important stability warning. Every sentence earns its place; there is no fluff or redundancy. The structure front-loads the essential information effectively.

  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 zero-parameter tool with no output schema, the description covers the key aspects: what it lists, the fields included, the JSON array format, and a caution about id stability. It does not explicitly mention behavior when no windows are present, but that is not critical. The description is sufficiently complete for an agent to call this tool correctly.

  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 tool has zero parameters and the schema description coverage is 100% (effectively no parameters to describe). The description does not need to add parameter semantics since there are none. Based on the rubric, with high schema coverage the baseline is 3, and the description does not add any extra parameter-related information because none exists.

  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: 'List the app's top-level windows' and enumerates the specific fields returned (id, title, class, geometry, and active status). It also specifies the return format as a JSON array. While the verb and resource are specific, it does not explicitly differentiate from sibling tools like glass_select_window or glass_window, though the 'list' action makes the distinction reasonably clear.

  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 does not provide any guidance on when to use this tool versus alternatives. It offers a behavioral warning about id instability, which suggests a usage pattern (re-list instead of caching), but it does not explicitly state when to choose this over related tools like glass_select_window or glass_window. No exclusions or context for selection are given.

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

• glass_clipboard_setA
  4/5.0
  Behavior4/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds a specific error condition ('Returns Unsupported where the backend can't provide clipboard access'), which goes beyond the annotations. This is useful context about a failure mode that an agent would not otherwise know.

  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 sentences with no filler. The primary action is in the first sentence, and the error condition in the second. Every word contributes to the tool's understanding.

  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 write operation with no output schema, the description covers the core behavior and the only notable edge case (Unsupported backend). It does not mention return values on success, but that is implied for a write operation and not essential. The absence of output schema means the description isn't required to explain return format.

  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% for the single 'text' parameter, with a clear description ('The text to write to the clipboard.'). The tool description does not add any additional meaning or nuance beyond the schema's own documentation, so it meets the baseline but adds no extra value.

  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 clear verb ('Write') and resource ('text to the app's clipboard'), with an explicit purpose ('so it can paste it'). It is easily distinguishable from its sibling 'glass_clipboard_get' since it names the opposite action (write vs. get).

  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 usage context is implied by the tool's name and description (write text to clipboard), but no explicit guidance is given about when to use this versus the sibling 'glass_clipboard_get' or any exclusions. The description does not mention alternatives, so it relies on the agent to infer from the sibling list.

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

• glass_scrollA
  4.1/5.0
  Behavior5/5

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

  The annotation set is minimal (only three false flags: readOnlyHint, openWorldHint, destructiveHint), so the description bears full weight and exceeds expectations. It clarifies the click-to-event mapping ('clicks |dx| times'), explicitly contrasts wheel notches with pixels, and explains the app's autonomy over the final mapping ('is the app's choice'). This is outstanding disclosure of behavior beyond the structured data.

  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 opening sentence is crisp, and the overall prose is well-proportioned. Some redundancy exists with the modifier description ('e.g.'-style language repeats in both the description and the `modifiers` field), but this is a minor fact, keeping it at a 4 rather than a 5.

  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 description is complete for a majority of invocation scenarios, and the clause 'How an app maps a wheel notch to its view (lines, pixels, zoom) is the app's choice' is an honest, transparent disclosure of side effects. It misses the opportunity to point to `glass_scroll_to_element`, but is otherwise a thorough and complete description for a call to correctly filter this 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?

  With schema description coverage at 100%, the baseline is 3. The description adds modest value by reinforcing key disambiguation like 'NOT pixels' and the clipping semantics, though these are largely mirrored in the schema documentation itself, keeping the description from a perfect score.

  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 'Scroll at window-relative coordinates by (dx,dy) wheel steps' states a precise verb (Scroll) and a specific, well-defined resource (window-relative coordinates). The unit (wheel notches) is unambiguous, making it clear what the tool does and how it differs from a scroll-to-element or a pixel-based scroll. It leaves no ambiguity about its core purpose.

  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 choose this tool over an alternative, especially the sibling `glass_scroll_to_element`. There is no when/when-not stated, and no mention of alternatives, leaving the decision entirely to the caller. This is a clear gap in usage guidance.

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

• glass_wait_stableA
  4.1/5.0
  Behavior4/5

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

  With readOnlyHint=true, the description adds useful behavioral detail beyond the annotation: it waits for stability, can ignore unrelated motion via stability_region, and can suppress the returned image. It does not contradict the annotations, and it explains the non-destructive observation behavior clearly.

  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 the core behavior front-loaded and no filler. Every clause adds useful information, and the text-mode optimization is included as a practical tip without bloating the description.

  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 9-parameter read-only tool, the description covers the essential behavior, the key parameter interactions, and the text-only result path. There is no output schema, and the description's `{settled,width,height}` shorthand is slightly less complete than the schema's fuller result description, but the schema already carries that detail.

  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 100%, so the description does not need to restate parameter details. It adds real value by clarifying the relationship between stability_region, region, and include_image:false, especially that region is ignored when include_image is false.

  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 clear verb and resource: wait for the window to stop changing, then return the settled frame. It is distinct from sibling tools like glass_wait_for_element or glass_wait_for_region, though it does not explicitly name them or say what they are for.

  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 usage context, including how stability_region narrows settling and when include_image:false is useful ('cheap before a text glass_diff'). It does not provide explicit when-not-to-use guidance or name alternative sibling tools, so it stops 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.

• glass_capabilitiesA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds valuable behavioral context: the tool is static (no session required), reports live status with specific enum values, and explains what each status implies (e.g., degraded means reduced fidelity, requires_setup means a setup step is missing). This goes beyond the annotations by detailing the response semantics.

  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 dense but well-structured, front-loading the purpose and then explaining the status values and parameter usage. It's a bit long but every sentence adds value, explaining the status enum and the `tools` field. The structure is logical: purpose, status explanation, parameter guidance.

  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 capability check tool with a single optional parameter and no output schema, the description is quite complete. It explains the status values, what they mean, and how to use the parameter. The only minor gap is that it doesn't explicitly state the return format beyond the status and tools fields, but given the tool's simplicity and the annotations, this is 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?

  The schema already provides 100% coverage of the `backend` parameter, including valid values and the behavior for omitted vs. invalid names. The description adds a brief note about omitting for the active backend, but the schema already covers this. Since schema coverage is high, the baseline of 3 is appropriate.

  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 reports which operations can be performed on a backend, listing specific operations (input, multi-touch, clipboard, accessibility, window move/resize) and the purpose (check before acting to avoid Unsupported errors). It distinguishes itself from siblings by focusing on capability reporting rather than performing actions.

  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 explicitly says to use this tool to check capabilities before acting, and explains the status values and what they mean for subsequent tool calls. It also specifies when to pass the `backend` parameter and when to omit it, providing clear guidance on usage.

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

• glass_select_windowA
  4.3/5.0
  Behavior4/5

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

  Beyond the annotations (idempotent, non-destructive), the description reveals a key behavioral trait: selecting a window redirects subsequent operations and changes the coordinate system. The schema description also warns that ids are not stable across calls, which is important operational behavior. This adds real value beyond the annotation flags.

  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 efficient: one sentence that states the action, the id source, and the consequential effect on later operations. Every clause earns its place, and the most important information is 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 single-parameter tool with no output schema and annotations covering safety, the description is complete. It tells the agent what to pass, where to get it, and what side effects to expect on future calls. Nothing essential is missing 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?

  The schema already covers the only parameter fully, describing it as a window id from glass_list_windows and noting instability. The main description merely repeats 'by id (from glass_list_windows)', adding no new meaning. With 100% schema coverage, the baseline of 3 is appropriate.

  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 ('Make a window active') and resource ('window'), and immediately identifies the source of the id ('from glass_list_windows'). This clearly distinguishes the tool from siblings like glass_list_windows, glass_screenshot, or glass_click by explaining that it sets the target for subsequent operations.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool: before screenshot/click/type/window operations, since those will target the selected window and interpret coordinates relative to it. It does not explicitly name alternatives or exclusions, but the usage pattern is strongly implied and reinforced by the schema's note about re-listing rather than caching ids.

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

• glass_wait_for_regionA
  4.3/5.0
  Behavior4/5

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

  The description is transparent about the blocking behavior, timeout (returns {matched:false}), and the fact that it returns text metrics unless include_image is set. It also explains side effects of window_id (does not change target window) and the interplay of ignore regions with changed_pct. The readOnlyHint annotation is consistent—this tool does not modify UI state—so there is no contradiction.

  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 dense but well-structured, packing key information about parameters, defaults, and return format into a single coherent paragraph. It avoids redundant repetition and flows logically from action to parameters to use case. While it is lengthy, it is appropriate for the tool's complexity and does not include superfluous 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?

  Given there is no output schema, the description sufficiently describes the return object {matched,changed_pct,bbox,elapsed_ms} and the condition for a false match (timeout). It covers edge cases such as clamping of ignored rectangles and the need for baseline in 'matches' mode. Minor gaps remain, such as error handling for missing baselines, but overall it provides enough context for correct usage.

  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?

  Even though the schema covers 100% of parameters with descriptions, the tool description adds meaningful semantic value beyond the schema. It clarifies relationships (e.g., 'until matches needs baseline', 'mode perceptual|exact with threshold/tolerance') and explains default behaviors. It also describes the effect of ignore regions on changed_pct measurement, which is not fully captured in the individual parameter descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb: 'Block until a visual region changes or matches, then return text metrics.' It distinguishes this tool from sibling wait tools (e.g., glass_wait_for_element, glass_wait_for_log) by targeting visual regions and comparing against baselines. The inclusion of usage direction ('Use "matches" to confirm the UI reached an approved design') reinforces the intent.

  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 concrete usage guidance, such as using 'matches' to confirm a UI state without spending vision tokens, and explains parameter combinations like 'until matches needs baseline.' It implicitly differentiates from alternatives by focusing on visual region changes rather than element presence or logs, though it does not explicitly enumerate 'when not to use.' Overall, it gives enough context for an agent to choose appropriately.

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

• glass_diffA
  4.4/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, so the description doesn't need to restate that. The description adds valuable behavioral context: it explains the error behavior for unsaved baselines ('an unsaved name errors rather than reporting no change'), the effect of `ignore` on `changed_pct`, and the region-relative bbox. This goes beyond the annotations and helps the agent understand side effects and edge cases.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose and return value, then the optional behavior. Every clause earns its place: the first sentence states the action and output, the second explains the optional parameter and its edge case. No fluff, no repetition of schema details.

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

  Completeness4/5

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

  Given the tool's complexity (7 params, 1 required) and the rich schema, the description covers the key behavioral aspects: error on unsaved baseline, ignore/region interaction, and conditional image return. It doesn't explain the return format in detail (no output schema), but the description mentions 'change stats + bbox' which is sufficient for an agent to know what to expect. The only minor gap is not explaining the `mode` and `threshold`/`tolerance` interplay, but the schema covers those.

  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 100%, so the schema already documents all parameters. The description adds value by explaining the interaction between `ignore` and `region` (intersection), the default behavior of `mode`, and the conditional return of `include_image`. It doesn't repeat schema details but adds semantic context that helps the agent choose parameters correctly.

  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 ('Diff'), a clear resource ('current frame against a named baseline'), and the return value ('change stats + bbox'). It also distinguishes itself from siblings like glass_wait_for_region and glass_baseline_save by naming the baseline concept and the optional image return. This is a clear, specific purpose that an agent can act on.

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

  Usage Guidelines4/5

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

  The description implies usage context: it's for comparing frames against a saved baseline, and the `include_image` option is explained. It doesn't explicitly state when NOT to use it or name alternatives, but the sibling list includes glass_wait_for_region and glass_wait_stable which are related; the description doesn't explicitly route to them. However, the context is clear enough for an agent to infer when to use this tool.

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

• glass_gestureA
  4.4/5.0
  Behavior4/5

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

  The description discloses that multi-touch isn't available on every backend and that it returns a clear Unsupported error where unsupported, which is valuable beyond the annotations (which declare only safety hints). It also explains the timing model (all down at t=0, up at duration_ms) and the 'held pointer' behavior, adding behavioral context that helps the agent anticipate results. The annotations don't specify these runtime behaviors, so the description fills a real gap.

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

  Conciseness5/5

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

  The description is concise and information-dense, front-loading the core action and mechanics in the first sentence, then adding gesture examples and a critical limitation note. Every sentence adds non-redundant value; there's no filler or repetition of schema details. It's well-structured for quick scanning by an agent.

  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 no output schema and a moderate-complexity parameter set (only two parameters), the description covers the essential semantics: pointer segments, gesture types, timing, and backend limitations. The only minor gap is that it doesn't explicitly state the default duration_ms, but that's in the schema description. Overall, an agent has enough to call it correctly without missing critical behavior.

  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 covers the parameters thoroughly, but the description adds glossary-level meaning: it defines what a 'from==to pointer' means (held), and clarifies how the pointer count maps to gesture types. It reinforces window-relative coordinate semantics already in the schema, and explains the duration default implicitly by describing the timeline. Since schema coverage is 100%, the description's additional gestures and examples go beyond repetition, earning a 4.

  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 ('perform'), a precise resource ('multi-touch gesture'), and enumerates pointer count and segment mechanics. It lists concrete gesture patterns (pinch, rotate, swipe, hold), which clearly distinguishes it from single-pointer tools like glass_drag and glass_click, and from other input tools such as glass_key or glass_type.

  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 gesture mechanics and provides examples of when to use each pattern (pinch, rotate, swipe), giving clear context. It doesn't explicitly say when NOT to use this tool versus alternatives, but the detailed gesture-specific guidance implies usage for multi-touch scenarios, leaving no ambiguity for common cases.

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

• glass_startA
  4.4/5.0
  Behavior4/5

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

  Adds behavioral context beyond annotations: explains that a11y is on by default, that passing false skips the accessibility bus for canvas apps, and that window_hint handles multi-window or handoff cases. This supplements the sparse annotations (readOnlyHint=false, destructiveHint=false) with useful details about defaults and 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 four sentences, front-loaded with the core purpose, and each sentence adds distinct value (backend, a11y, window_hint) without fluff or repetition. 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 tool with 9 parameters and a nested object, the description covers the most critical aspects (purpose, backend, a11y, window_hint) while leaving parameter details to the schema. It doesn't explicitly mention return format beyond 'window geometry' (no output schema), but that is adequate for the complexity. Minor gap: it doesn't summarize the env behavior on android or the timeout, but these are clearly documented in the schema.

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

  Parameters4/5

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

  With 100% schema coverage, the baseline is 3, but the description adds value: it explains the backend default, gives a pragmatic reason for a11y:false (canvas/pixel-only apps), and clarifies window_hint's purpose. This goes beyond simply repeating schema descriptions.

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

  Purpose5/5

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

  The description states a specific verb+resource: 'Build, launch, and locate a native GUI app; returns its window geometry.' This clearly distinguishes it from sibling tools like glass_list_windows (which lists windows) and glass_select_window (which selects), making the tool's 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?

  Provides clear usage context: how to choose a backend, when to pass a11y:false, and how to use window_hint for disambiguation. However, it does not explicitly mention alternatives like 'use glass_list_windows if you just need to list windows,' so it lacks explicit exclusions, but the purpose is distinct enough that context is clear.

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

• glass_clipboard_getA
  4.5/5.0
  Behavior4/5

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

  Annotations already mark readOnlyHint=true, so the description adds value beyond that by disclosing edge cases: "" if empty and "Unsupported where the backend can't provide clipboard access." It also explains the ctrl+a/c Ctrl+c workflow as an implementation detail. No contradiction with readOnlyHint.

  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, front-loaded with the primary purpose, then the secondary use case. Every clause contributes information: return value, empty-handling, workflow hint, OCR comparison, and failure mode. No waste.

  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 zero-parameter read-only tool with no output schema, the description covers the essential behavioral contract: what it returns (text), empty case, and the Unsupported state. It also ties into the broader tool ecosystem with the glass_do reference, making it complete for an agent to call correctly.

  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 schema coverage is trivially 100%. The description cannot add parameter-level meaning, but it does not need to. The baseline for 0-param tools is 4, and the description doesn't introduce any ambiguity about inputs.

  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 clear verb ("Read") and resource ("the app's clipboard"), and specifies the return type (text) and empty-string behavior. It also differentiates from siblings like glass_clipboard_set by framing itself as the read counterpart and adding a specific text-extraction use case.

  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 provides a concrete usage scenario: "the cheap text-extraction path" using glass_do ctrl+a then ctrl+c, and explicitly compares to OCR ("beats OCR for selectable text"). It lacks explicit exclusion criteria or when-not-to-use guidance, hence not a 5, but the context is clear enough for an agent to select correctly.

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

• glass_scroll_to_elementA
  4.5/5.0
  Behavior5/5

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

  Annotations are minimal (readOnlyHint=false, destructiveHint=false) and carry little behavioral weight, so the description does the heavy lifting — and it is exceptionally thorough: it discloses the sweep-and-reverse strategy, the vertical down→up fallback when the target isn't in the tree, the anchor-on-target-row/column behavior for off-center containers, and the {matched:false} timeout failure mode. No contradiction with annotations; scrolling as a state change is consistent with readOnlyHint=false.

  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 core purpose is front-loaded, but the single paragraph is dense and repeats information already captured in the schema field descriptions (defaults of 3 and 20000ms, anchoring behavior, direction-inference fallback all appear in both places). The extra behavioral detail is valuable, yet the redundancy with the 100%-coverage schema makes it longer than it needs to be.

  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?

  With no output schema and no required parameters, the description bears full responsibility for explaining returns and behavior — and it delivers: it spells out the exact return shape ({matched, elapsed_ms, element{id,role,name,bounds,states}, scrolled{steps,reversed,direction}}, {matched:false} failure), the error case when no a11y tree exists, and the visibility requirement linking to glass_click_element. Nothing an agent needs to call it correctly 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 coverage is 100%, so baseline sits at 3. The description adds a small layer of meaning on top: it frames 'step' as a 'calibration escape hatch' with a stepping-past warning, and motivates the x/y defaults with the top-toolbar example. Much of the parameter detail (defaults, direction inference, anchoring) duplicates the schema's own rich field descriptions, so the added value is present but modest.

  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?

  Opens with a specific verb+resource+goal: 'Scroll a container (any axis) until an accessibility element is on-screen, then return it.' The scope is precisely delimited (scroll-to-target and return an actionable id), and it names its downstream consumer (glass_click_element), which distinguishes it from the plain glass_scroll sibling without opening either schema.

  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 on when to use it: to bring an element on-screen so its returned id is usable with glass_click_element, and it notes the visibility requirement ('actually visible — not merely present in the a11y tree'). It does not, however, explicitly state when NOT to use it versus the alternative glass_scroll, leaving part of the selection decision to inference.

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

• glass_wait_for_elementA
  4.5/5.0
  Behavior5/5

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

  The description goes far beyond the readOnlyHint annotation by disclosing timeout behavior ({matched:false}), error behavior when no element appeared, the returned JSON shape with an id usable in glass_click_element, and that it waits through a just-launched app's accessibility tree publication. These are substantive behavioral traits an agent needs.

  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?

  Every sentence carries load-bearing information: purpose, selectors, condition list, return shape, id reuse, timeout semantics, launch-wait behavior, and the anti-pattern it replaces. There is no fluff or repetition, and the most critical facts 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?

  Despite having no output schema, the description fully covers return values, failure/timeout modes, selector constraints, and post-return usage of the element id. The schema covers per-parameter details like interval_ms and timeout_ms defaults, so nothing critical is missing for an agent to invoke the tool correctly.

  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 schema already documents every parameter in detail, including defaults, enums, and the non-standalone constraint on value_contains. The description briefly restates conditions and the default but adds little beyond what the schema provides, so the baseline of 3 is appropriate.

  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: 'Block until a UI element reaches a precise state, then return it as text (no image).' It clearly defines the object of the wait (an accessible UI element), the action (blocking/waiting), and the output modality (text, not image), which distinguishes it from screenshot-based wait tools.

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

  Usage Guidelines4/5

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

  The description provides clear context: selectors must be name/role, condition defaults to appears, and the tool collapses screenshot poll-loops into one call. It does not explicitly state when not to use this tool or point to alternatives like glass_wait_stable or glass_wait_for_region, but the use case is well grounded.

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

• glass_wait_for_logA
  4.5/5.0
  Behavior5/5

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

  Discloses blocking semantics, timeout behavior returning {matched:false}, the exact return shape, cursor semantics, and the default time window. Annotations mark this as readOnly and non-open-world, and the description adds timing and continuation behavior without contradiction.

  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 four sentences, dense and front-loaded with the core action. Every sentence contributes essential behavior, and the detailed return-shape note is warranted because no output schema exists. It is slightly longer than minimal but not wasteful.

  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 blocking timeout tool with no output schema, the description fully covers return values, timeout behavior, and cursor continuation. All 5 parameters are documented in the schema, and optional poll/default settings are present. Minor gaps like explicit error cases do not undermine usability.

  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 100%, but the description adds meaningful semantics beyond the schema: it clarifies that cursor from glass_logs can catch a pre-existing line, explains the resume behavior, and highlights stream optionality. This exceeds the baseline for fully-covered schemas.

  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?

  Description states a specific verb ('Block until...'), resource ('log line'), and conditions ('contains', optional 'stream'). It clearly differentiates from sibling tools like glass_logs by emphasizing wait-until behavior and from other wait_* tools by focusing on logs and cursor semantics.

  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?

  Description gives practical context: default behavior matches only new lines, pass a cursor from glass_logs to catch an earlier line, and resume from returned cursor. It references glass_logs explicitly, implying a usage sequence, but does not state explicit when-not-to-use or name alternative tools beyond glass_logs.

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

• glass_a11y_snapshotA
  4.6/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint=true, and the description goes beyond by disclosing determinism, low-token output, the exact line format, that 'desc' is display-only and not used for selection, error conditions, and the renumbering of ids when max_nodes changes. No contradictions 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.

  Conciseness4/5

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

  The description is dense but well-organized: it front-loads the purpose and format, then explains nuances (desc display-only, error fallback, max_nodes) and integration notes. Every sentence contributes, though it could be tightened slightly for readability.

  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 no output schema, the description is remarkably complete: it defines the output format precisely, covers error handling and the fallback, explains how ids are used downstream, and details max_nodes behavior. An agent has everything needed to call it correctly.

  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 max_nodes is fully documented in the schema (100% coverage), including the default cap, passing 0 for no limit, and the renumbering side effect. The description repeats 'raise the element cap' and 'default caps protect the token budget' without adding new semantics, so it stays at the baseline for high 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 specific action ('Capture the active window's accessibility tree') and the resource, including the exact output format. It distinguishes itself from glass_screenshot (image vs. text tree) and other element-related tools by spelling out the addressing mechanism and its integration role.

  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?

  It explicitly tells the agent when to fall back to glass_screenshot (when the app exposes no accessibility tree), names sibling tools (glass_wait_for_element, glass_scroll_to_element, glass_click_element) and explains how to use the snapshot's output with them, and signals when it complements screenshots. This is clear conditional usage guidance.

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

• glass_set_valueA
  4.6/5.0
  Behavior5/5

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

  Annotations only state it's not read-only and not destructive. The description far exceeds that by detailing the write strategies, the up-to-three accessibility reads for confirmation, the exact error conditions and their implications (transformed text, dropped keystrokes, no effect), and explicit retry prohibitions. This gives the agent deep insight into the tool's runtime behavior with no contradictions.

  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 long but well-organized: purpose first, then mechanics, error conditions, and finally the optional parameter. Every sentence carries substantive detail, and the error-handling guidance is wrapped into the behavioral description. It could be slightly tightened without losing value, but the complexity justifies the length and structure.

  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?

  With no output schema, the description covers all needed runtime information: the input requirements, the optional return value behavior (including what 'snapshot' returns), error conditions with remediation steps, and what not to retry. An agent has everything it needs to invoke this tool correctly and recover from failures, making it highly complete for its complexity.

  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 100%, but the description adds crucial nuance beyond the schema: it explains that `id` must come from `glass_a11y_snapshot`, that `text` has type-specific interpretations (spin/slider, switch/checkbox, dropdown), and it clarifies the `return` parameter's three modes (snapshot, settle, none) beyond the schema's wording. This meaningfully enhances the schema, though a baseline of 3 is already met.

  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-resource pair: 'Set an editable element's value', and immediately ties it to 'pick the element's #id from glass_a11y_snapshot'. This clearly differentiates it from sibling tools like glass_click or glass_type by naming the exact action and the required input source.

  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 two execution modes (direct write vs typed fallback) and provides explicit error-handling rules, including when NOT to retry (the 'already typed' error). It implicitly positions the tool as the way to set values on editable elements, but it never explicitly names alternative tools like glass_type or glass_click for comparison, so usage guidance is clear but not contrastive.

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

• glass_typeA
  4.6/5.0
  Behavior4/5

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

  Annotations already mark this as a write (readOnlyHint=false) but the description goes well beyond: it clarifies the tool does not focus anything itself, is keystroke-based rather than a paste, and that newlines do not trigger Return. The `return` snapshot/settle semantics are also explained. 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.

  Conciseness4/5

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

  Four dense sentences, each carrying distinct information (focus requirement, keystroke behavior, alternative, return semantics). Somewhat long but front-loaded with the core caveat ('does not focus') and nothing is filler.

  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?

  Covers the focus prerequisite, per-key vs paste semantics, the newline/Return behavior, the preferred alternative glass_set_value, and the full behavior of the optional return parameter including the cache refresh side effect. Complete for a typed-input 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 100%, so baseline is 3. The description adds real value: the newline-does-not-press-Return caveat for `text`, and the snapshot-cache-refresh semantics for `return`, which the schema only summarizes. It clarifies behavior beyond the schema's property descriptions.

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

  Purpose5/5

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

  'Type a string of text into the focused window' states a specific verb, object, and scope in one sentence. It explicitly differentiates itself from glass_set_value, which targets the a11y tree, and glass_key for discrete keys — a model can route correctly without opening the schema.

  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?

  Exceptionally explicit: it tells the agent to click the field first (naming glass_click_element / glass_click), flags that a newline won't press Return and must be a separate glass_key, and instructs to prefer glass_set_value when the a11y tree exposes the field. Routing decisions are spelled out, not left to inference.

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

• glass_a11y_marksA
  4.7/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, and the description aligns with that by describing a read-only operation. It adds context about the precision of bounding boxes (~10-20px drift), how clicks are actuated (native accessibility action vs center), and error behavior. The only minor gap is not detailing what the legend format is for elements with both a name and description, but the overall transparency is strong.

  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 dense but perfectly scannable: it opens with what the tool does, explains the legend format, then covers precision, click mechanism, and error handling. Every sentence adds unique information with no fluff.

  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?

  Despite being a zero-parameter tool, it fully explains the output format, error conditions, precision limitations, and how to use the output. The error fallback to glass_screenshot is a nice operational detail.

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

  Parameters4/5

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

  The tool has 0 parameters, and schema coverage is 100%. The description doesn't need to add parameter info since there are none. It adds value by explaining the return format (image + legend) which goes beyond 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 tool takes a screenshot of the active window with numbered boxes on interactable elements (Set-of-Mark) and returns the image plus a text legend. It distinguishes itself from siblings by using the phrase 'Pick an element visually, then click it with glass_click_element using its #id', and mentions it returns errors differently than glass_screenshot.

  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?

  It explicitly says when to use it: 'Pick an element visually, then click it with glass_click_element using its #id', and when it's not appropriate: 'Errors if no accessibility tree is available — use glass_screenshot then.' It also clarifies the relationship with glass_click_element and glass_a11y_snapshot.

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

• glass_baseline_saveA
  4.7/5.0
  Behavior5/5

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

  The description discloses several important behaviors beyond the annotations: capturing the whole window at call time rather than a saved region, silent replacement on overwrite, storage outside the app in a per-server directory, and persistence until server exit. These are exactly the kind of behavioral details an agent needs.

  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 dense but every sentence contributes: it defines the baseline, explains the capture scope, discloses replacement and lifetime semantics, and routes to alternatives. The most important purpose is 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 single-parameter tool with no output schema, the description is complete. It covers what the tool does, how it behaves, what conditions matter, and which sibling to choose instead. Nothing an agent needs to decide whether to invoke it 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 schema already fully describes the single `name` parameter, including allowed characters and overwrite behavior. The description adds baseline semantics and capture scope, but not additional parameter-level detail, so the high-coverage baseline of 3 is appropriate.

  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: 'Save the current frame as a named visual baseline.' It clearly distinguishes the tool from siblings by explaining what glass_diff and glass_wait_for_region use it for and explicitly contrasts it with glass_screenshot.

  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?

  Gives explicit when-to-use guidance: use this with glass_diff to detect change, and use glass_screenshot when you need to inspect pixels. Also provides a timing constraint—settle the UI first if it is still animating—which is practical usage advice.

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

• glass_click_elementA
  4.7/5.0
  Behavior5/5

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

  The description thoroughly discloses side effects and nuances: it can click occluded/off-screen elements via the native action, falls back to pointer click, routes clicks into popover windows, and restores the previous window. It explains result fields and id validity. Annotations (`readOnlyHint=false`, `destructiveHint=false`) align with a click action that is not read-only but not destructive. No contradictions.

  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 long but dense; every clause adds functional detail. It front-loads the primary action and then layers edge cases and result semantics. While a bit verbose, it avoids redundancy and is organized logically (method, fallback, routing, id validity, return options).

  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 complex behavior and no output schema, the description covers all critical aspects: actuation paths, fallback reasons, popover routing, id freshness, return options, and result fields. An agent has enough to call it correctly and interpret results without guessing.

  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 coverage is 100% with detailed parameter descriptions, and the description goes further: it explains id scoping to the latest snapshot, popover routing, the `return` parameter's effects (refreshing cache, settling), and the meaning of result fields. This adds substantial value beyond the raw 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 specifies the exact action: clicking an element by its a11y snapshot id, and explains the two actuation paths (native accessibility action vs synthetic pointer click) and the result fields (`method`, `native_fallback`, `actuated_id`). It clearly differentiates this from coordinate-based clicking (sibling `glass_click`) by anchoring to snapshot ids.

  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 states the prerequisite clearly: you need an id from `glass_a11y_snapshot`, and re-runs the snapshot if the UI changed. It also covers the popover routing case and the optional `return` modes. However, it does not explicitly contrast with alternatives (e.g., `glass_click` for coordinates or `glass_set_value` for text) — though the context implies when to use it.

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

• glass_doA
  4.7/5.0
  Behavior5/5

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

  The description richly discloses behavioral traits beyond the annotations. It explains that `settle` waits for the screen to stop changing between steps, the optional `then` runs after all actions succeed (with order settle → diff → screenshot), and it fails fast: if an action errors it reports which index failed and how many ran. It also notes that partial sequences may already have landed, which is critical for the agent to understand side effects. It explicitly rejects `type`'s `return` observe inside actions, and clarifies that `then` is text-only unless screenshot/diff image. This is substantial behavioral context that the annotations (readOnlyHint=false, destructiveHint=false) do not provide, and it does not contradict them.

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

  Conciseness5/5

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

  The description is well-structured and appropriately sized for a complex tool. It front-loads the core purpose (collapsing round-trips) and then progressively provides details on actions, settle, then, and fail-fast behavior. Every sentence adds value: the example use cases (login, form-fill, menu→item) are concise and illustrative, and the warning about not batching when you need to see a result is crucial. There is no redundant content, and the structure (core purpose → details → usage guidelines) is logical and efficient.

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

  Completeness5/5

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

  Given the tool's complexity (nested actions, optional `then` with settle/diff/screenshot), the description is remarkably complete. It covers the key behaviors an agent needs: the action types, settle behavior, `then` semantics, fail-fast error reporting, and the restriction on `type`'s `return`. The output schema is not present, but the description implicitly explains what the tool returns (e.g., which index failed and how many ran, text-only results unless screenshot/diff image). The annotations provide minimal safety info (readOnlyHint=false, destructiveHint=false), but the description compensates for the lack of output schema and gives enough context for correct invocation. No critical gaps are apparent.

  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 has 100% description coverage for the two top-level parameters (`actions` and `then`), and the nested action types are thoroughly documented. The description adds value by summarizing the structure of `actions` (list of objects with action field) and the optional `then`'s fields, but the detailed parameter semantics (e.g., per-action fields, `then`'s order) are already in the schema. The description does not add additional meaning beyond what the schema provides, but it reinforces key points like the rejection of `type`'s `return` in actions. Since schema coverage is 100%, baseline is 3, but the description's clarification of the `then` order and the `type` restriction nudges it to a 4.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: runs an ordered sequence of input actions in one call, collapsing round-trips, with optional observation. It specifies the verb (run), resource (input actions), and mode (ordered sequence). It also distinguishes from siblings by explicitly listing the action types (click, move, drag, scroll, type, key, settle) and the use cases (known sequences like login, form-fill). While it doesn't name a sibling directly, it contrasts with the alternative of calling individual tools, making the unique purpose clear.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance on when to use this tool: for KNOWN sequences (login, form-fill, menu→item) and when not to use it (if you must see a result to choose the next action, don't batch that part). It also mentions that `type`'s `return` observe is rejected inside actions, guiding the agent to use `settle` or `then` instead. While it doesn't name specific alternative tools like `glass_click` or `glass_type`, it clearly contrasts with the per-action round-trip approach, which is sufficient. No explicit exclusion of other tools, but the conditional guidance is strong.

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

• glass_screenshotA
  4.8/5.0
  Behavior5/5

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

  Beyond the readOnlyHint, the description discloses critical behaviors: clipping when reaching off-screen, the meaning of returned dimensions (actual captured size), and the error condition for fully off-screen surfaces. This is valuable transparency not covered by 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 concise—two sentences—and efficiently packs key information: the primary function, optional region, clipping behavior, error condition, and parameter semantics. No fluff 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?

  Given the tool's complexity (optional region, off-screen handling, window targeting), the description covers all essential aspects. It explains return semantics (clipped dimensions) and edge cases (fully off-screen errors), making it complete for an agent to use without further clarification.

  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?

  Both parameters (region and window_id) are explicitly described in the tool description with practical semantics (e.g., 'omit for the whole window', 'without changing which window subsequent ops target'). The schema also provides detailed descriptions, but the added context ensures full understanding.

  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 (capture), the resource (app window or optional region), and the output format (lossless WebP). It differentiates from sibling tools by focusing on screenshots, and the mention of clipping/off-screen errors adds specificity.

  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 implicitly signals when to use this tool (need a screenshot) but does not explicitly contrast with alternatives. It could be improved by stating 'use this when you need a visual representation' or naming sibling tools. However, it provides clear behavioral constraints that guide usage.

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

• glass_stopA
  4.8/5.0
  Behavior5/5

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

  The description goes far beyond the annotations by explaining the graceful shutdown behavior, the slower force-termination fallback, the loss of session-scoped logs and a11y element ids, the persistence of saved baselines, and the no-resume guarantee. This fully discloses the destructive consequences of the call.

  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 longer than strictly necessary but every sentence carries relevant operational information: shutdown mechanics, session scope, persistence, no-resume, and usage frequency. It is front-loaded with the core action and then builds context logically without unnecessary filler.

  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 zero-parameter schema and the destructive nature of the operation, the description is complete. It tells the agent exactly what will happen, what will be lost, what will survive, when the tool should be called, when it should not be called, and what happens when no session exists.

  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 coverage is 100%, so there are no parameter semantics to document. The description appropriately does not invent parameter-related detail, and the baseline for zero-parameter tools is satisfied.

  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: 'Stop the running app and end the session.' It clearly differentiates from glass_start by stating there is no resume and only glass_start runs the app again as a fresh session, so an agent can distinguish this from sibling tools.

  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 is explicit about when to use the tool: it is not needed between steps of a task, one session can be driven for as long as needed, and it errors if no session is running. It also directs the agent to glass_start as the only alternative for starting a fresh session.

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

• glass_dragA
  4.9/5.0
  Behavior5/5

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

  The description thoroughly discloses behavior beyond annotations: it presses at the start point, moves in steps over duration_ms, releases at the end, holds modifiers throughout, and refuses endpoints outside the window with an error giving window size. Annotations (readOnlyHint=false, destructiveHint=false) are consistent, and the description adds significant operational 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?

  Every sentence earns its place: behavior, coordinate system, button/modifier semantics, error handling, and sibling differentiation. The description is information-dense but not padded, and the most important facts 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 pointer-input tool with no output schema, the description covers all essential invocation context: valid use cases, coordinate frame, parameter behavior, error conditions, and alternatives. An agent has everything needed to call this tool correctly.

  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 100%, so the baseline is 3. The description adds meaningful context beyond the schema by clarifying defaults ('button is left'), behavior over time ('moves across in steps over duration_ms'), and coordinate semantics in narrative form. It reinforces and slightly extends the schema, warranting a 4.

  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: dragging with a button held from (x1,y1) to (x2,y2). It clearly differentiates from siblings by stating glass_gesture is the multi-touch equivalent and glass_click is the press-and-release-in-place case, so an agent can disambiguate immediately.

  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?

  It explicitly says when to use the tool: 'Use this for a single pointer — selecting text, moving an item, resizing a pane.' It also names the alternatives and the conditions that select them, leaving no ambiguity about choosing glass_gesture or glass_click.

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

• glass_logsA
  4.9/5.0
  Behavior5/5

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

  Annotations only declare readOnlyHint=true and openWorldHint=false, but the description adds substantial behavioral context: the resumable cursor semantics, immediate non-blocking return, buffer rotation that can age out unread lines, and the fact that returned lines are marked untrusted. This goes far beyond what annotations provide and contradicts nothing.

  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?

  Four dense sentences, each earning its place: the core operation, cursor behavior, the blocking alternative, filtering guidance, and the buffer/untrusted caveats. The most important information is front-loaded and no sentence is wasted.

  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 4 optional parameters, no output schema, and read-only annotations, this description covers everything needed to call it correctly: what it returns, how cursors resume, empty-return behavior, when to choose the waiting sibling, filtering options, and buffer limitations. Nothing essential 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the cursor's loop-once semantics, why filtering server-side matters, and how the buffer can cause unread lines to be dropped. It doesn't detail every parameter, but the schema already documents them well.

  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: 'Read captured stdout/stderr log lines with a resumable cursor.' It clearly distinguishes this from the sibling glass_wait_for_log by explaining the non-blocking behavior, so an agent can tell which tool to pick 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 explicitly says to use glass_wait_for_log when blocking is desired ('it does not wait, so use glass_wait_for_log when you want to block until a line appears'). It also advises server-side filtering with stream and contains instead of reading everything, giving clear guidance on how to use this tool efficiently.

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

• glass_doctorA
  5/5.0
  Behavior5/5

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

  The description discloses that the deep option spawns and tears down a headless display, implying side effects, which aligns with the annotations. It also details the return structure (sections, checks, statuses, remedies) and overall verdict, providing full transparency about 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 well-structured and concise, covering purpose, usage, parameter, and output in a logical flow. It avoids redundancy and each sentence adds value, despite being somewhat detailed for the return structure.

  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?

  The description fully explains the tool's functionality, optional deep behavior, and the complete structure of the returned data, including status values and remedy fields. It leaves no ambiguity for an agent using this tool.

  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 only parameter 'deep' is fully described: 'Also spawn and tear down the default backend's headless display to verify it actually starts (slower). Default false.' Schema coverage is 100%, so the parameter semantics are complete and clear.

  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 diagnoses the glass environment and reports per-check status, with a specific verb and resource. It also mentions the self-diagnosis use case, effectively distinguishing it from sibling tools that perform other actions.

  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 explicitly instructs 'Use this to self-diagnose a glass_start failure', providing a precise when-to-use scenario. It also explains the optional deep check, making the tool's intended usage unambiguous.

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

• glass_keyA
  5/5.0
  Behavior5/5

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

  Beyond the generic annotations, the description discloses valuable behavior: case-insensitive modifier aliases, rejection of unrecognized tokens with an error naming the token, atomicity (nothing is half-pressed), and modifier release on completion. No contradiction with the annotations exists.

  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 dense but well-organized: examples first, then grammar, key types, error semantics, and finally sibling routing. Every sentence earns its place and no filler is present.

  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 single-parameter tool with no output schema, the description covers everything needed to invoke it correctly: exact syntax, accepted keys, modifier handling, error behavior, and when to choose it over glass_type. Nothing essential is missing.

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

  Parameters5/5

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

  The input schema only provides a single example string, while the description fully explains chord grammar, accepted modifier names, aliases, key categories, case-insensitivity, and error behavior. This adds substantial 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 clear verb and resource ('Press a key chord') with concrete examples, and it explicitly distinguishes itself from glass_type. An agent can immediately tell what this tool does and how it differs from its sibling.

  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?

  It explicitly says to use this tool for shortcuts and named keys and notes that glass_type is for literal text and cannot express either. The chord syntax and modifier rules are also clearly described, leaving no ambiguity about when and how to use it.

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