windows2-mcp

by verisoft-ai

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is overlap between window management tools (maximize_window vs maximize_current_window, similar for minimize and restore) which could cause confusion. Also, analyze_screen and find_by_vision serve similar visual analysis needs, though their descriptions clarify different use cases.
Naming Consistency4/5
The majority of tools use a consistent verb_noun pattern (e.g., find_element, click_element, get_text). However, a few tools break the pattern, such as switch_to_window_by_title (longer than necessary) and the use of 'and' in click_and_drag. Overall, the naming is predictable with minor inconsistencies.
Tool Count3/5
With 87 tools, the server covers an immense amount of functionality for Windows application automation. While each tool seems justified by the complexity of the domain, the count is at the high end and could be overwhelming. Some advanced input tools (advanced_click, perform_actions, click_and_drag) might benefit from consolidation.
Completeness4/5
The server covers a comprehensive range of actions: session management, element finding, interaction, window handling, keyboard/mouse input, UIA patterns, and file operations. Notable gaps are minimal, such as the lack of a direct tool for taking a full screenshot (only element screenshot and screen recording available) and the IE-only context switching tools.
Average 4/5 across 87 of 87 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only mentions 'click and drag' without explaining the simulation mechanics (e.g., mousedown, mousemove, mouseup), whether the action is continuous or discrete, or how coordinate systems work. The durationMs parameter hints at timing but is not described. This is insufficient for a complex action.
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, no wasted words. The first sentence front-loads the primary action, and the second adds concrete usage examples. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is far too brief. It does not explain coordinate systems, return values, error conditions, or behavior when element IDs are omitted. The description is incomplete for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22% (only endElementId and startElementId have descriptions). The tool description adds no parameter-specific meaning at all. It does not explain what startX/startY/endX/endY represent (pixels, relative to what?), the unit of durationMs, or the effect of modifierKeys. Despite the low coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'click and drag' and the resource 'from one position to another'. It also lists three use cases: resizing, reordering, or moving elements. While it does not explicitly differentiate from sibling tools like 'click_element' or 'advanced_click', the action is unique enough that the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by listing example use cases (resizing, reordering, moving elements). However, it does not give explicit guidance on when not to use this tool or point to alternatives among the many sibling tools. The implied usage is adequate but lacks exclusionary criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as clipboard overwriting, error handling for invalid base64, or return behavior. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise at one sentence, but lacks essential details. Could be shorter if trimmed, but brevity here sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no output schema, no annotations), the description is incomplete. It omits behavior for different content types, return value, and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no new meaning beyond the schema, achieving baseline 3.
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 sets clipboard contents from a base64-encoded string, matching the name and distinguishing it from the sibling get_clipboard.
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 on when to use this tool versus alternatives, no prerequisites, nor when to avoid it. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint: false. The description does not disclose any behavioral traits beyond what the annotation implies. It fails to mention whether clearing triggers events, works on disabled elements, or what happens to non-input elements—important details for an agent to anticipate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the core action. However, it omits useful details that could be added in one more sentence, so it is not maximally informative.
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 one-parameter tool with no output schema, the description is minimally adequate. It fails to explain what the tool returns (void), what types of elements are supported (only input elements?), or how it interacts with other tools. The sibling set shows many related actions, so more context would help the agent choose 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 input schema provides full coverage with a clear description for elementId ('Element ID returned by find_element'). The tool description adds no extra semantic meaning about the parameter, so it meets but does not exceed the baseline for full 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?
Description clearly states the action ('Clear') and the target ('text content of an input element'). This distinguishes it from sibling tools like set_value (which sets new text) or get_text (which reads text). The verb+resource pairing is specific and 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 provided on when to use clear_element instead of alternatives like set_value, send_keys, or set_element_value. There is no mention of prerequisites (e.g., element must be interactable) or context in which clearing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that the position is relative to the app window, which is useful context beyond the schema. However, it does not disclose what happens if the element is not visible or not attached to the DOM, and there is no output schema to clarify the exact return format.
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, clear sentence that directly conveys the tool's purpose. It is front-loaded with the action and resource, and contains no extraneous words. It could be slightly improved by front-loading what it gets (position/size) before the parenthetical detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, annotations, and no output schema, the description provides a basic level of completeness. However, it does not mention the return type or structure, which is important for an agent to use the output. The description also lacks context about coordinate system or potential errors (e.g., stale element).
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?
With 100% schema description coverage, the baseline is 3. The description does not add any extra meaning beyond the schema for the single parameter elementId. It does not elaborate on what constitutes a valid elementId (e.g., a recently returned ID, or its type structure).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the position and size') and the resource ('an element'), with specifics about the coordinate reference ('relative to the app window'). This distinguishes it from get_window_rect (which gets the browser window's position/size), but does not explicitly differentiate from other getter tools like get_element_info or get_element_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_element_info (which may return similar bounding box data) or get_window_rect. The description does not mention prerequisites (e.g., that find_element must be called first), nor does it clarify when calling this tool is appropriate versus other element query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares idempotentHint=true, and the description does not contradict this. However, it does not elaborate on what happens to the window (e.g., whether it goes to taskbar, if focus shifts, or if the element becomes invalid). Given the annotation covers idempotency, a score of 3 is appropriate as the description adds minimal behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point. It could be slightly improved by front-loading the action more clearly, but it is efficient and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and the idempotent annotation, the description is mostly adequate. However, it lacks any mention of return value or side effects (e.g., whether a new window state can be queried). For a simple tool, this is acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter elementId. The description adds no additional meaning beyond what the schema provides. Baseline 3 is correct when the schema fully covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Minimize' and the resource 'a window element via the UIA Window pattern'. It specifies the action precisely and differentiates from siblings like maximize_window, restore_window, and close_window by naming the specific pattern used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as minimize_current_window or close_window. The description does not explain prerequisites (e.g., element must represent a window), nor does it indicate when this is preferred over other window manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so agents know it's a safe read operation. The description adds context about the UIA Value pattern, which hints at platform-specific behavior but does not disclose what happens if the element lacks the pattern or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and method, no wasted words. Efficient and direct.
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 tool with one parameter and read-only annotations, the description is mostly adequate. However, it does not explain what 'value' means in the UIA context (e.g., text, numeric), nor does it describe the return format or error behavior, leaving some ambiguity given no output 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% (elementId description 'Element ID returned by find_element'). The tool description adds no further meaning beyond the schema, meeting the baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'value of an element via the UIA Value pattern', indicating a specific UI automation mechanism. It differentiates from siblings like get_text or get_attribute by referencing the UIA Value pattern, but does not explicitly contrast with alternatives.
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 on when to use this tool versus siblings such as get_text or get_element_info. The description lacks any when-to-use, when-not-to-use, or prerequisite information, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects (e.g., whether selection state changes immediately, whether the container must support multi-select, or error conditions like attempting removal on single-select). The reference to 'UIA SelectionItem pattern' hints at automation behavior but lacks explicit behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. Every word adds value, making it highly 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?
Given the tool has one parameter and no output schema, the description covers the core purpose. However, it lacks details on prerequisites (e.g., container must support multi-select) and error handling, which are important for an interactive automation tool.
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% with one required parameter 'elementId' described as 'Element ID returned by find_element'. The description does not add new semantics beyond the schema; it merely states the parameter's role implicitly.
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 ('Remove an item from the current selection'), the context ('multi-select container'), and the mechanism ('UIA SelectionItem pattern'). It distinguishes from sibling tools like 'add_to_selection' and 'get_selected_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an item is selected in a multi-select container, but does not explicitly state when to use this tool versus alternatives like 'clear_element' or 'click to deselect'. No prerequisites or fallback guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action without explaining what happens when no parameters are provided (all optional), how coordinates and elementId interact, or the effect of default delta values. The schema covers parameter formats, but the description lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the verb, and contains no redundant or irrelevant information. Every word earns its place, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 optional parameters, no output schema, no annotations), the description provides the essential purpose but omits nuances like default behavior, parameter interaction, and expected results. It is minimally adequate but leaves significant gaps for an agent to infer 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 high (83%+), and the description does not add any meaning beyond what the schema already provides for each parameter. The baseline score of 3 is appropriate because the schema adequately documents the parameters, and the description does not detract from or enhance that 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 verb 'scroll' and the resource 'mouse wheel at an element or screen coordinate', which precisely defines the tool's function. It is distinct from sibling tools like 'scroll_element_into_view' or 'hover', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., scroll_element_into_view, click_and_drag). It does not mention prerequisites, fallback behavior, or when not to use it, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to 'stop' a recording and 'return' the video, which is a state-changing operation. However, the annotations declare 'readOnlyHint: true', suggesting the tool is read-only. This is a direct contradiction. Additionally, the description does not disclose side effects (e.g., whether the recording file is deleted after return) or authentication requirements for remote upload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core action, and the second explains the two modes of output. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters and no output schema, the description explains the output format (base64 or remote upload) but fails to cover side effects (e.g., whether the recording is saved or discarded) or provide behavioral context for the large number of upload parameters. It meets the minimum viable but leaves gaps in understanding full 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?
Schema description coverage is 100%, providing baseline clarity for all 7 parameters. The description adds value beyond the schema by explaining the default behavior (return base64) and the conditional behavior when 'remotePath' is provided. However, it does not elaborate on the remaining upload-related parameters beyond what the schema states.
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 ('Stop') and resource ('screen recording'), and clearly states the action and output (return the video). It distinguishes itself from its sibling 'start_recording_screen' by focusing on stopping and returning the recording.
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 guidance on when to use this tool vs. alternatives, such as needing to call 'start_recording_screen' first. There is no mention of prerequisites or when not to use it, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, and the description correctly implies a non-destructive state change with no side effects. However, the description does not explicitly confirm idempotence or clarify what happens if the element is already collapsed.
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 clear sentence that efficiently conveys the tool's purpose. No extraneous words, but it could be slightly enhanced with a one-word note about idempotence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema, no output schema, and annotations, the description is adequate. It covers the core purpose but lacks context on prerequisites (element must be expanded) and no-failure behavior.
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 does not add details about the elementId parameter beyond what the schema provides.
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 ('Collapse') and the resource ('expanded element') using the specific 'UIA ExpandCollapse pattern'. It differentiates from sibling tools like expand_element and toggle_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for elements that are already expanded and support the ExpandCollapse pattern, but it does not explicitly state when to use it vs. expand_element or toggle_element, nor does it exclude non-expanded elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, indicating safe repeated calls. The description adds 'via the UIA Window pattern' which offers a technical detail but little behavioral context beyond what annotations convey.
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, front-loaded sentence with no wasted words. However, it could be improved by including usage context, making it slightly less than perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema) and high schema coverage, the description provides minimally adequate context. It could better explain the element type or how it differs from similar window tools.
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%, as the single parameter 'elementId' already has a clear description in the schema. The tool description does not add additional meaning or constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Maximize' and the resource 'a window element' via the UIA Window pattern. It distinguishes from sibling tools like minimize_window, restore_window, and close_window by specifying the pattern and that it operates on a window element.
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 on when to use this tool versus siblings like maximize_current_window or minimize_window. The description does not mention prerequisites (e.g., element must be a window) or contexts where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'destructiveHint: true' already signals a destructive operation. The description adds that it uses the UIA Window pattern, but does not elaborate on behavioral traits (e.g., whether the element becomes invalid, if the window handle is removed, or any side effects). With the annotation, the baseline is met but little extra value is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loading the key action and resource. Every word contributes; there is no fluff. It is appropriately sized for a simple, single-purpose tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema, annotations present), the description is adequate but lacks depth. It does not explain what 'UIA Window pattern' implies or how the tool differs from similar window-closing operations. The agent may need additional context to use it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes the 'elementId' parameter meaningfully. The tool description does not add any additional semantic context beyond what the schema provides. Baseline score 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 action ('close') and the resource ('window element via the UIA Window pattern'). It is specific and distinguishes 'close_window' from siblings like 'click_element' or 'invoke_element' which have different effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not explain why one would choose 'close_window' over clicking a close button via 'click_element' or using 'invoke_element'. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions mouse movement and optional modifier keys, but does not explain what happens with out-of-bounds coordinates, whether the pointer actually moves smoothly over intermediate points, or if it just teleports. The behavior is partially disclosed but with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and to the point. Every word adds value, and there is no redundancy or fluff. It earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is somewhat under-informative. It covers the high-level purpose but does not explain return values (e.g., success indicator, new coordinates), required parameters, or error conditions. The tool is relatively simple, so the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, with most parameters having no description. The tool description does add meaning by explaining the overall action, but it does not add details for individual parameters beyond what the schema already has (e.g., durationMs, endElementId, startElementId have some description in schema). The high-level description partially compensates but leaves many parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves the mouse pointer from one position to another, optionally with modifier keys. It distinguishes its purpose by mentioning hover effects and drag-without-click, which helps differentiate it from sibling tools like click_element or click_and_drag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some context about when to use it (for hover effects and drag-without-click), but does not explicitly say when not to use it or mention alternatives like click_and_drag or perform_actions. It provides basic guidance but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the `readOnlyHint` annotation by naming the UIA Selection pattern and stating the return value. However, it omits crucial details like what happens when no item is selected (e.g., error, null) or whether it works on non-container elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundancy. All information is front-loaded and directly helpful.
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 read-only tool with one well-documented parameter and no output schema, the description is mostly complete. It could be improved by mentioning behavior when no selection exists, but overall it provides sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `elementId` is fully documented in the input schema (100% coverage). The description does not add any extra meaning or constraints beyond what the schema already provides, so baseline score 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get', the resource 'first selected item in a container', and the mechanism 'via the UIA Selection pattern'. It also mentions the return type 'element ID', distinguishing it from siblings like `get_all_selected_items` and `select_item`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as `get_all_selected_items` (for multi-select) or `select_item`. The agent is left to infer appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a safe read operation. The description adds the 'visible' qualifier, which clarifies that hidden text is not included, but does not detail return behavior (e.g., empty string for no text) or other operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. It is appropriately sized, front-loaded with the action, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, a single required field, and no output schema, the description sufficiently covers purpose and expected behavior. It could mention the return type (string) for completeness, but overall it is adequate for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with elementId already documented as 'ID returned by find_element'. The description adds no additional parameter-level meaning, so the baseline of 3 applies because the schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('visible text content of a UI element'). It distinguishes itself from siblings like get_attribute and get_element_info by focusing specifically on visible text content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions or scenarios where other tools like get_attribute or get_page_source would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds the clarification 'enabled and interactable,' which gives some behavioral context beyond the annotation, but does not discuss return values, error behavior, or 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 a single, concise sentence with no wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only boolean check with one parameter and no output schema, the description is mostly sufficient. It clearly states what is checked, though it could mention that the result is a boolean or describe what happens when the element is not found.
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 documents the single parameter elementId with a description. The tool description does not add additional semantic meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('UI element') and clearly differentiates the action from siblings like is_element_displayed and is_element_selected by focusing on 'enabled and interactable'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., is_element_displayed, is_element_selected). The usage context is entirely implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It adequately describes the default case-insensitive substring matching and the effect of the 'exact' parameter. However, it omits important behavioral details such as what happens if no matching window is found, whether the operation is synchronous, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, is front-loaded with the core purpose, and contains no extraneous words. Every sentence earns its place—first states the action, then explains matching behavior and the optional parameter.
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 tool with two parameters and no output schema, the description covers the key usage aspects (matching strategy, exact vs substring). It lacks details on error handling (e.g., no match, multiple matches) or return value, but these are less critical for a focus-switching action. The description is mostly complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description adds slight value by explaining the default matching behavior ('substring match') and how 'exact' modifies it, but these details largely echo the schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Switch focus to a window by its title' with a specific verb and resource. It explains the default substring matching behavior, making the tool's function unambiguous. However, it does not explicitly contrast with sibling tools like 'switch_to_window' (which likely uses a window handle), so differentiation relies on the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (by title) and describes the optional 'exact' parameter for stricter matching. It implies use when you have a partial or full window title, but does not explicitly state when not to use it (e.g., if you have a handle instead) or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail that an empty string is returned when the attribute is absent, which is not conveyed by the annotation (readOnlyHint: true). However, no other behavioral traits (e.g., auth needs, side effects, rate limits) are disclosed. The description does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences, each adding unique value. No fluff or redundant information. Perfectly front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with read-only annotations and no output schema, the description covers purpose, common attributes, and return value behavior. The schema covers the parameter details. The description is complete enough for an agent to use 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%, so baselines at 3. The description lists common attribute names, but the schema already provides examples. The description does not add new semantic meaning beyond what the schema offers for the 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 verb ('Get') and the resource ('attribute or property of a UI element'). It lists common attributes, which helps distinguish from sibling tools like get_text, is_element_enabled, or get_element_info. The purpose is specific and 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 provided on when to use this tool versus alternatives like get_element_info, get_text, or is_element_displayed. There is no mention of when-not-to-use or any prerequisites. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already indicates this is a read-only operation. The description adds that the output is 'base64-encoded,' which is useful but does not disclose potential side effects (e.g., clipboard content consumption on some platforms) or formatting nuances. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the key verb 'Read' and conveys the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, read-only annotation), the description covers the core functionality. However, it lacks details about error conditions (e.g., empty clipboard, unsupported formats) or platform-specific behavior, which could be important for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is fully documented in the schema. The description does not add additional meaning beyond what the schema's description already provides (e.g., plaintext vs image). Baseline 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 verb ('Read'), the resource ('current clipboard contents'), and the output format ('base64-encoded string'). It is concise and distinguished from sibling tools like set_clipboard (which writes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading clipboard data, but it does not explicitly state when to use it versus alternatives or provide prerequisites (e.g., clipboard access permissions or platform-specific behaviors). No guidance is given for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so description's behavioral burden is lower. Description adds that it checks on-screen visibility (not just existence), which is useful, but doesn't clarify if hidden/zero-size elements return false or error.
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?
Single sentence conveys complete purpose. No filler, no repetition of schema details. Perfectly concise.
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 single parameter, full schema coverage, readOnlyHint, and no output schema, description is adequate. Could mention return type (boolean) since no output schema, but omission is minor.
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 has full description for elementId, so baseline is 3. Description reinforces that the elementId comes from find_element, adding context on tool chaining. This justifies a 4.
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?
Clearly states it checks UI element visibility on screen. Specifies 'not off-screen' to disambiguate from general display checks. Distinguishes from sibling tools like is_element_enabled or is_element_selected.
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?
Implies use for verifying visibility before interacting, but no explicit when-to-use or when-not-to-use guidance. No mention of alternatives among siblings like is_element_enabled or is_element_selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false. The description adds valuable behavioral details: it clears the element before typing and works without window focus. This goes beyond annotations, though it does not discuss side effects like event triggering or error conditions.
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, no unnecessary words. The core action and key behavioral note are front-loaded. Every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of many similar sibling tools (set_element_value, send_keys), the description provides some distinguishing context but lacks explicit comparison. No output schema exists, yet the description does not mention what the tool returns, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what is in the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the text value of an input element, specifying that it clears first then types. This distinguishes it from similar siblings like 'clear_element' and 'send_keys', but does not explicitly differentiate from 'set_element_value', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the tool does not require the window to be focused or in the foreground, which is useful context for choosing it over typing actions. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is destructive (corroborating the destructiveHint annotation) and does not end the session. It adds value by clarifying the session remains active, which is not in the annotation. However, it does not disclose other behaviors like whether the app can be reopened within the same session, what happens to elements, or if closing fails gracefully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, both of which are essential. It front-loads the action and constraint without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, clear action), the description is mostly complete. However, it omits what happens after closing (e.g., can you relaunch?), any prerequisites (is the app already open?), or side effects (are stored references invalidated?). For a destructive action with no output schema, a bit more context would help the agent reason about consequences.
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 no parameters and schema coverage is 100%, so the description has little to add. The description does not need to explain parameters, making it sufficient. The score reflects that the description adds no new param info, but given the context, that is acceptable.
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 (close the application under test) and the constraint that it does not end the Appium session. It distinguishes from delete_session, which likely ends the session. However, 'under test' could be more precise (e.g., the current app or context), and without seeing delete_session's description, the distinction is implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Only call when explicitly asked,' which provides a usage guideline. This helps prevent accidental use. However, it does not explain when to use this tool vs. others like close_window or delete_session, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true already flags the tool as destructive. The description adds 'launch a new app instance' which implies resource consumption and user confirmation, but does not disclose other behavioral traits such as session lifecycle, resource cleanup, or what happens if a session already exists. With annotations present, the description provides adequate but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second gives a critical usage instruction. It is front-loaded, concise, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich schema, the description is misleading: it says 'Launch a Windows application' but the schema allows attaching to an existing window via appTopLevelWindow without launching. It also does not explain what the tool returns (e.g., a session ID) or how to use the result with other tools. For a complex tool with 17 parameters and no output schema, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The tool description does not add any additional parameter meaning beyond what is in the schema. The baseline is 3 for high coverage, and the description does not enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Launch a Windows application and start a new Appium session.' This specifies a distinct verb and resource, and the sibling tools (attach_session, delete_session) make it obvious this is for creating a new session, not attaching or deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'Ask the user before calling — confirm they want a new app instance launched.' This is strong guidance on when to use the tool. However, it does not explicitly contrast with attach_session (e.g., 'use this for launching new apps, attach_session for existing ones').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; the description adds behavior like 'Returns an error if not found' and gives a strategy priority list. It does not contradict annotations and provides useful behavioral context beyond the structured annotation alone. A minor gap: no mention of potential side effects (though read-only implies none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph with a numbered list for strategy order. Every sentence serves a purpose: purpose, return value, error behavior, strategy ranking, and post-use advice. No redundancy; front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a moderately complex set of sibling tools (find_elements, find_child_element), the description leaves gaps: it doesn't specify if multiple matches cause an error or return first match; it doesn't contrast with find_child_element; the return value ('element ID string') is vague. The strategy guidance partially compensates, but completeness is adequate but not thorough.
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% with detailed enum descriptions for 'strategy' and a description for 'selector'. The description adds value by recommending an order of strategies and suggesting post-use call to 'get_element_info', which helps the agent use parameters effectively. The added context is meaningful but not essential given the already rich 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 'Find a single UI element in the current app window' with a specific verb and resource. It distinguishes from sibling 'find_elements' (plural) but does not explicitly contrast with 'find_child_element' or clarify behavior when multiple elements match (e.g., returns first or error).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a 'Preferred strategy order for reliable automation' and recommends calling 'get_element_info' after interaction, which guides parameter selection. However, it lacks explicit guidance on when to choose this tool over siblings like 'find_elements' or 'find_child_element', leaving the decision partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which the description's 'Get' verb supports non-destructive behavior. However, the description does not disclose edge cases (e.g., behavior when no element has focus, return value format, or error handling). With annotations present, the description adds minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 13 words conveys the complete purpose efficiently. Every word earns its place; there is no redundancy or waste.
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 no parameters and no output schema, the description covers the primary use case clearly. However, it omits edge cases (e.g., no focused element) and does not specify the return type or format of the element ID. Given the simplicity, it is mostly complete but could be slightly more thorough.
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?
There are zero parameters, so schema coverage is trivially 100%. The description correctly omits parameter details. Per guidelines, baseline for 0-param tools is 4, and the description fulfills this without needing to explain 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 uses a specific verb ('Get') and resource ('element ID of the element that currently has keyboard focus'), clearly distinguishing it from sibling tools like get_element_info or get_text. It uniquely identifies the active/focused element, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., get_element_info, get_text), nor does it mention when not to use it or what prerequisites are needed (e.g., must have a focused element). Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=false, which the description does not contradict. The description adds value by clarifying idempotent re-launch behavior—important for a launch tool. It doesn't detail startup delays, auth requirements, or background process behavior, but for a tool with good annotation coverage, the additional context about re-launch is sufficient. 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?
The description is a single, well-framed sentence that front-loads the verb and resource. It adds a valuable parenthetical about re-launch without any fluff. Slightly higher for a zero-param tool, though it could be made even more explicit about idempotency (e.g., 'safe to call multiple times').
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 has no parameters, no output schema, and a clear annotation, the description is largely complete. It explains what happens (launch or re-launch) and implicitly requires a prior session. For a simple action with low complexity, this suffices. However, it doesn't mention if launching multiple times spawns duplicate windows or is safe, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% description coverage, so the baseline is high (3). The description adds no param-specific info because none exist, but it doesn't need to—the schema fully covers parameters. The description earns a 4 for effectively clarifying the tool's scope (no configuration needed) beyond the empty 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 the tool launches the application configured for the session, including re-launching if closed. This is a specific verb ('launch') and resource ('application configured for this session'), which distinguishes it from siblings like 'close_app' or 'attach_java_swing'. However, it doesn't explicitly contrast with 'create_session' or 'attach_session', which could be related—leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning the application is 'configured for this session', suggesting it should be used after a session exists. However, it gives no explicit guidance on when not to use it (e.g., if already running) or alternatives among 70+ siblings. The parenthetical about re-launch hints at idempotent behavior but stops short of clear best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates safe read-only behavior. The description adds value by specifying the base64 return format and the requirement for 'modify_fs' feature. However, it does not disclose details like behavior on missing files, permission errors, or if file size limits apply, which would enhance transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose and a key prerequisite without any wasted words. It is front-loaded with the action and resource, and every part of the 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?
Given the tool has only one parameter with 100% schema coverage, no output schema, and a simple value retrieval operation, the description sufficiently covers the most critical aspects. Minor gaps exist (e.g., behavior on errors), but overall it provides a complete picture for a straightforward tool.
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 input schema has 100% coverage with a single parameter (remotePath) described as 'Absolute path of the file to read'. The description does not add additional meaning beyond what the schema already provides, so a baseline score 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 ('Read') and resource ('file from the filesystem of the machine running the driver'), clearly indicating the action and scope. It includes the return format ('base64') and distinguishes from siblings by noting it's for reading, not pushing or deleting files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the requirement for 'modify_fs' insecure feature, which provides context for when the tool can be used. However, it does not explicitly differentiate when to use pull_file vs other file tools like push_file or delete_file, nor does it mention alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation already tells the agent that running this multiple times has the same effect. The description adds that it works via the UIA Window pattern, which is useful but not critical. It does not mention any side effects (e.g., does it fail if window is already normal?) or permission requirements. With the annotation covering the idempotency, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It clearly states the action, the condition (minimized/maximized), the result (normal state), and the mechanism. Every part 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?
Given the simple single-parameter tool with annotations and full schema coverage, the description is complete enough. The only minor gap is not mentioning what happens if the window is already normal, but this is inferred from the idempotentHint. No output schema exists, so the return value is not explained, but that is acceptable for a simple action.
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 parameter 'elementId' is already documented in the input schema. The description does not add any extra meaning about the parameter beyond what the schema provides. The baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('restore') plus a clear resource ('a minimized or maximized window') and specifies the outcome ('to its normal state'). It also references the underlying mechanism ('via the UIA Window pattern'), which helps distinguish it from sibling tools like minimize_window or maximize_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when a window is minimized or maximized and you want to return it to normal state. However, it does not explicitly state when NOT to use it, nor does it mention alternatives or prerequisites (such as needing a valid elementId from find_element or get_window_element).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool toggles elements and suggests a verification step, but fails to mention permissions, error cases (e.g., non-toggleable elements), side effects, or return value. Adequate but not thorough.
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 remarkably concise with exactly two sentences: the first defines purpose and the second offers a actionable recommendation. No extraneous content exists.
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 single-parameter tool with no output schema, the description is largely complete. It names the action, target elements, and a follow-up step. It implicitly assumes knowledge of the UIA Toggle pattern, but overall provides sufficient context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any additional meaning beyond what is already in the input schema, which has 100% coverage with a clear parameter description. Baseline score 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 verb 'Toggle' and specifies the resources 'checkbox or toggle button' along with the mechanism 'via the UIA Toggle pattern'. This distinguishes it from sibling tools like click_element or invoke_element, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a post-action guideline ('call is_element_selected after this') but does not explicitly state when to choose toggle_element over alternatives like click_element or expand_element. The usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already provides readOnlyHint=true, so the description adds no extra behavioral context. It simply restates the tool's function without disclosing any additional traits such as return format or 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 a single clear sentence with no wasted words. It is front-loaded and immediately communicates the tool's purpose.
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 parameterless tool with no output schema and simple functionality, the description is complete enough to understand what the tool does and when it might be used.
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 no parameters (schema coverage 100%), the description need not add parameter details. Baseline score of 4 applies as the description does not detract from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'current date/time on the Windows device'. It is specific and distinct from sibling tools that focus on sessions, elements, windows, or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what it does, not the context in which it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares the tool as non-destructive. The description adds the specific return content (position and size) but does not disclose any additional behavioral traits like whether it requires an active session or handles multi-monitor scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose with no wasted words. It is front-loaded and easy to parse.
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 no parameters, no output schema, and a read-only annotation, the description covers all essentials: what it gets (position and size) and the scope (current app window). No missing information for successful use.
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 zero parameters, the input schema fully covers all inputs. The description adds meaning by stating what the tool returns (position and size), which is sufficient. Baseline for 0 parameters is 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 'Get the position and size of the current app window' uses a clear verb 'Get' and specifies the exact resource (position and size of current window), making it distinct from sibling tools like get_window_handles or get_window_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_window_element, get_windows, or set_window_rect. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the non-obvious behavioral requirement that the modify_fs insecure feature must be enabled on the Appium server. The destructiveHint annotation already indicates destructive behavior, so the description supplements it with a specific configuration constraint. It does not, however, detail overwrite behavior or directory creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core action and a critical prerequisite. Every word is necessary; there is no redundancy or fluff. It is front-loaded with the main purpose.
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 write operation with two well-described parameters and a destructive annotation, the description covers the main action and a key prerequisite. However, it is missing information about overwrite behavior, directory creation, return values (no output schema), and error states, which an agent might need to use the tool confidently.
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 input schema already provides descriptions for both parameters (base64Data and remotePath) with 100% coverage. The description adds no additional semantic meaning or examples beyond what the schema provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write a file') and the target ('filesystem of the machine running the driver'). It distinguishes from sibling tools like pull_file, delete_file, and delete_folder by specifying the write operation. The added prerequisite (modify_fs feature) further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (requires modify_fs insecure feature), which provides some usage guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., pull_file, other file operations), nor does it provide conditions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool modifies the active context (a behavioral trait not covered by any annotations, as none are provided). It does not disclose potential side effects, such as whether the UIA element tree changes or if element references become invalid after switching. Since there are no annotations, the description carries the full burden but only partially discloses behavior.
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 of 20 words, making it highly concise. It front-loads the action ('Switch the active context') and then provides concrete examples. Every phrase earns its place. Minor improvement could be structuring with bullet points for clarity, but the current form is effective.
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 only one parameter and no output schema, the description is largely sufficient. It explains both valid input categories and hints at a prerequisite (calling get_contexts). However, it could be more complete by mentioning that switching context may invalidate previous element references, which would help the agent avoid errors. The sibling tools are diverse, but this description adequately differentiates set_context from the rest.
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 adds meaning by explaining the specific values accepted ('NATIVE_APP' or 'WEBVIEW_<id>'), which goes beyond the schema's generic 'Context name to switch to'. However, it does not clarify formatting nuances of the WEBVIEW_<id> or error handling, so it does not exceed the baseline significantly.
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: to switch the active context. It specifies the exact verb ('switch') and resource ('active context'), and distinguishes from sibling tools by explaining the two possible input values ('NATIVE_APP' for UIA tree, or a 'WEBVIEW_<id>' from get_contexts), which sets it apart from other context-related tools like get_current_context or get_contexts.
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 on when to use each type of input (return to native app or switch to webview), and implicitly guides the agent to first call get_contexts to obtain the WEBVIEW_<id> values. However, it does not explicitly state when NOT to use this tool or name any alternatives, slightly lowering the score from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It clearly discloses that the tool uses the 'UIA SelectionItem pattern' and explicitly states the key non-destructive behavior: it 'does not deselect existing items'. This provides essential behavioral context beyond the parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the action, target, mechanism, and critical behavioral note. Every part earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (1 parameter, no output schema, no nested objects), the description adequately covers the purpose, mechanism, and key behavior. It does not explain return values, but with no output schema defined, some users might expect guidance on what the tool returns (e.g., success/failure). However, the tool's simplicity makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning beyond the input schema for the single parameter 'elementId'. Since the schema description coverage is 100% and the schema already states 'Element ID returned by find_element', the description provides no additional parameter semantics. Baseline score 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 verb 'Add', the resource 'item to the current selection in a multi-select container', and explicitly distinguishes from a deselect behavior by noting 'does not deselect existing items'. This provides a specific and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to add an item to a multi-select selection without clearing existing selections, but it provides no guidance on when not to use this tool (e.g., for single-select containers or when you need to replace the selection) or any alternatives among the many sibling tools like 'select_item' or 'remove_from_selection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=false, which is obvious for a click. The description adds transparency by noting it does not require window focus/foreground—a non-obvious behavioral detail that helps the agent understand side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no wasted words. Every sentence adds unique value: the first defines the action, the second clarifies a key behavioral trait.
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 has a single parameter, no output schema, and simple semantics, the description is adequate. It explains the unique behavior (no focus requirement) that an agent might not infer. Could optionally mention what happens if the element is not found or not clickable, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter elementId already described in the schema. The description adds no additional semantics about the parameter (e.g., how to obtain it, format constraints), so baseline 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 ('Click') and resource ('UI element by its element ID'). It clearly states what the tool does and distinguishes it from siblings like 'advanced_click', 'invoke_element', or simply 'click' (which may behave differently).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests when to use (when you have an element ID and want to click without focusing the window), but does not explicitly state when not to use or offer alternatives among the many sibling tools (e.g., 'advanced_click' for double-click, 'invoke_element' for non-click actions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals mutability. The description adds a valuable behavioral constraint: the 'modify_fs' feature must be enabled. This is non-obvious from the schema or annotation alone. However, it does not disclose potential failure modes (e.g., non-existent file, permission errors) or mention that deletion is permanent (no trash).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. The action is front-loaded, and the prerequisite is stated in a separate sentence. Every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema). The description covers the action and the security requirement. It does not explain the return value or error handling, but for a straightforward delete operation, this is a minor gap. Overall, it is sufficiently complete for its complexity.
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% (the single 'path' parameter is fully described in the schema). The description adds no further parameter details beyond what the schema already provides (absolute path). Baseline 3 is appropriate since the schema carries the burden.
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 (delete), the resource (a file on the machine running the driver), and the non-negotiable prerequisite (requires 'modify_fs' insecure feature). This is specific and distinguishes it from siblings like delete_folder or push_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical prerequisite for using the tool, but it does not explicitly state when to use it vs. alternatives (e.g., move to trash, rename, or use a different tool). It implies usage for file deletion, but lacks explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation already indicates the tool is safe to retry. The description adds modest behavioral context by referencing the UIA ExpandCollapse pattern, but does not discuss edge cases (e.g., expanding an already expanded element) or side effects. With annotations present, the description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter action tool, the description is mostly complete. It lacks an explanation of the return value (since no output schema exists), but the usage is intuitive. The annotation provides idempotency context. Minor gaps reduce the score from 5 to 4.
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% with a clear description for elementId. The description does not add any parameter information beyond what the schema provides, so baseline score 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 ('expand') and resource ('collapsible element') with examples (tree node, combo box, menu) and mentions the UIA pattern. This clearly distinguishes it from siblings like collapse_element, toggle_element, and click_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it expands collapsible elements via the UIA ExpandCollapse pattern. It implicitly tells the agent when to use this tool, but does not explicitly exclude alternatives like collapse_element or toggle_element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare idempotentHint: true, which is already transparent. The description adds minor behavioral context (UIA Focus pattern, Windows-specific terminology) but does not elaborate on potential side effects (e.g., what happens if element is not interactable) or permissions needed. With annotations covering the key trait, the description's additional value is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero redundancy: the first sentence states the core action, and the second provides critical usage guidance. Every word earns its place, making it highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, idempotentHint annotation, and no output schema, the description adequately covers the essential context (action, prerequisite, platform hint). It could be slightly more complete by noting that the element must already be found, but that is implied by elementId referencing a prior find_element result, which the schema's description already states.
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 description does not add additional meaning beyond what the schema already provides for the single parameter (elementId). The baseline of 3 is appropriate since the schema fully documents the parameter, and the description offers no extra insight.
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 'set focus to an element' via a specific pattern (UIA Focus, windows: setFocus), providing both the action and the resource (an element). It distinguishes itself from siblings like click_element or send_keys by being a prerequisite for keyboard interactions, making its purpose specific and non-overlapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Required before keyboard-driven interactions such as send_keys on a specific control', giving clear guidance on when to use this tool. However, it does not mention when not to use it or list alternative tools for unrelated contexts, missing the full picture of exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context by explaining the dual interpretation of the tag name based on context (native vs. webview). No contradictions or missing safety traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and efficiently adds clarifying context in parentheses without extra words. Perfectly concise for a simple tool.
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 explains the return value semantics fully (UIA vs. HTML tag). With no output schema, this is adequate. The single parameter is thoroughly described in the schema. No mention of error behavior, but acceptable for a straightforward read operation.
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% (elementId well-documented). The tool description does not add further parameter-level meaning beyond the schema, so baseline 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 action ('Get an element's tag name') and clarifies the context-dependent meaning (UIA ControlType for native, HTML tag for IE/webview), which distinguishes it from siblings like get_attribute or get_element_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_attribute or get_text. The description explains what the tool returns in different contexts, but does not provide usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, confirming it's non-destructive. The description adds that it retrieves the 'Name property of the root window element', which is useful detail beyond the annotation. However, it doesn't clarify if the title refers to the native OS window title or the application's internal title, nor what happens if the window is not found or has no title. Since annotations already cover the main behavioral trait, the description adds moderate value here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, with no filler. It front-loads the action 'Get the title' and immediately specifies what that means. Every part is necessary.
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 parameters, no output schema, and simple read-only behavior, the description is mostly complete. It explains what the tool does and the source of the title (root window element's Name property). The only minor gap is not clarifying the scope of 'current window' (e.g., whether it's the active window or the one associated with the current session/context). An agent might infer correctly, but explicit context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and is fully documented (100% coverage). The description's mention of 'current window' implies the tool operates on an active context, which is reasonable. With zero parameters, the description doesn't need to add much, but it could clarify what 'current window' means (e.g., the active window in the session). The baseline for high coverage is 3, and the description adds a small amount of semantic context, 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 clearly states it gets the title (Name property of the root window element) of the current window. The verb 'get' and resource 'title of the current window' are specific and distinct from sibling tools like get_window_rect, get_current_window_handle, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing what the tool does, but provides no guidance on when to use it versus alternatives (e.g., get_text on a specific element vs. this tool for the entire window title). No exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the UIA Invoke pattern and that it does not simulate mouse input, but does not disclose potential failure modes, permissions, or side effects. Adequate for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The description is front-loaded with the core action and immediately gives context (UIA pattern, no mouse input).
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 tool with one parameter and no output schema, the description is fairly complete. It covers purpose, behavioral difference from clicking, and usage condition. Could mention return value or error handling, but not essential.
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 parameter description is clear ('Element ID returned by find_element'). The description adds no additional meaning beyond the schema, so baseline 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's purpose: 'Invoke the default action of an element via the UIA Invoke pattern without simulating mouse input.' This distinguishes it from siblings like click_element, which simulates mouse input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use for elements that do not respond to mouse clicks.' This provides clear guidance for selection, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the safe read nature is covered. The description adds value by revealing that the check relies on the 'UIA Selection pattern', giving the agent insight into the underlying mechanism. It does not contradict annotations. No mention of error cases or prerequisites, but for a simple query that's acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 20 words. Every word serves a purpose: verb, subject, condition, and even the underlying technology ('UIA Selection pattern'). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, readOnly annotations), the description adequately explains the tool's purpose. However, it could improve by explicitly stating the return type (boolean) since no output schema is present. The current description implies a yes/no answer but doesn't guarantee it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one required parameter (elementId) that is well-described as 'Element ID returned by find_element'. The tool description adds no additional parameter context beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check whether' and clearly identifies the resource: 'a container (e.g. ListBox) allows multiple items to be selected via the UIA Selection pattern'. This directly distinguishes it from sibling tools like is_element_selected (which checks a single element's selection state) and is_element_enabled (checks enabled state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need to determine multi-select capability of a container, but it gives no explicit context about when NOT to use it or alternatives. For example, it doesn't mention that is_element_selected or get_selected_items might be more appropriate for checking actual selection state. Usage guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the action but does not clarify side effects, such as changes to the browser's history stack, or potential failure when no prior history exists. The behavior is simple but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core function and a keyboard shortcut hint without any filler. It is optimally concise for a simple navigation tool.
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 zero-parameter schema and simple action, the description is largely complete. However, it could briefly mention that the tool requires an existing session with navigable history or that it mimics a browser shortcut, which would aid agents in understanding constraints.
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% (empty). The description adds no parameter details, which is acceptable since none are needed. Baseline for 0 parameters is 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 action ('navigate back') and the scope ('in the current window's history') with a keyboard shortcut hint. It distinguishes this tool from its sibling 'navigate_forward' by specifying direction.
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 is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives (e.g., navigate_forward) or prerequisites. The description does not mention conditions like requiring a window with history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the underlying automation pattern (UIA SelectionItem) and the target controls (list box, tab control, combo box), but does not specify any side effects, required permissions, or failure modes (e.g., what happens if elementId is invalid or the item is already selected). This is adequate but not comprehensive.
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 that are front-loaded with action and purpose, every clause adds value. The technical detail about the UIA pattern is included without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no output schema, no nested objects, 100% schema coverage), the description is complete enough. It covers what the tool does and when to use it. A small gap is not explaining the return value or confirming successful selection, but the lack of output schema lowers expectations.
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 input schema has 100% coverage with elementId already described as 'Element ID returned by find_element'. The description adds no additional meaning beyond confirming the control types, which is already reasonable from the tool name and schema. Baseline 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 verb 'select', the resource 'item in a list box, tab control, or combo box', and the specific automation pattern (UIA SelectionItem). It also explains that this is the preferred method over click when click does not trigger selection, distinguishing it from similar tools like click_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool when 'click does not trigger selection', providing a clear when-to-use context. However, it does not mention any when-not-to-use scenarios or alternative tools like invoke_element for non-selection actions, which would have made it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=false, indicating a safe operation. The description adds the UIA pattern context, but does not mention prerequisites (e.g., element must be enabled, visible) or potential side effects. It adds some value beyond annotations but not extensive detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of 14 words. It immediately conveys the core action and mechanism with examples. No extraneous words; every phrase 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?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers the purpose and mechanism. It could briefly mention return behavior or error conditions, but is largely complete for an agent to understand the tool's role.
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% (both parameters described in schema). The description does not add additional semantic information about parameter values, formats, or constraints. Baseline is 3 due to high schema coverage, and no extra info is provided.
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 core action ('Set the value of an element'), the specific UI automation pattern used ('UIA Value or RangeValue pattern'), and concrete examples ('sliders, spin boxes'). This effectively differentiates it from sibling tools like 'set_value' or 'click_element'.
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 strong cues about when to use the tool by mentioning the specific patterns and examples. However, it lacks explicit guidance on when not to use it (e.g., for standard input fields where 'send_keys' may be more appropriate) or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly notes the auto-restore behavior (key for success) and the null-unchanged semantics. However, it omits potential side effects, required permissions, platform dependencies, and error conditions for out-of-range values (only schema min/max exist). This is adequate but incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by key behavioral and parameter guidance. No unnecessary words. Highly efficient.
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 covers the primary behavior (move/resize, auto-restore, null semantics) adequately for a tool with 4 required-but-nullable parameters and no output schema. However, it could mention what happens on success (return value?), error scenarios (e.g., invalid window state), and whether coordinate bounds are enforced beyond schema validation. Minor gaps for a mutating tool.
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's description already states 'New ... or null to leave unchanged.' The description repeats this guidance but adds no additional nuance, like units (pixels?), coordinate system origin, or constraints. Since schema does the heavy lifting, a 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's function: 'Move and/or resize the current session's root window.' It uses a specific verb (move/resize) and resource (root window). This distinguishes it from sibling tools like maximize_window, minimize_window, and get_window_rect.
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 context for when to use the tool: it mentions that move/resize fails when the window is maximized or minimized and that it first restores to normal state. It also explains how to leave dimensions unchanged via null. However, it does not explicitly contrast with alternatives like maximize_window or manual screen coordinate queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It clearly explains the scoping effect ('element finds are scoped to that frame's document') and the prerequisite (IE context), which is good transparency for a context-switching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding unique value: what the tool does, the scoping effect, and usage constraints. No waste and front-loaded with the primary function.
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 low complexity (3 optional params, no output schema, no nested objects), the description covers purpose, scoping, and constraints well. It could mention that after using this tool, switch_to_default_content or switch_to_parent_frame can go back, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a basic description (e.g., 'Frame name or id attribute'). The tool description adds context about using exactly one parameter and the IE-specific constraint, but does not add deeper semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches context into an iframe or frame inside an IE window, and that subsequent element finds are scoped to that frame. This verb-resource pair is specific and distinguishes it from siblings like switch_to_parent_frame and switch_to_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is only supported in IE context after switch_to_window, and requires exactly one of three parameters. It does not mention when not to use it or alternatives like switch_to_default_content, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose that switching windows may cause the previous window's elements to become stale, nor any permissions or side effects beyond focusing.
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?
Extremely concise single sentence that front-loads the action and context. No extraneous words, every part 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?
With a simple single-parameter tool and no output schema, the description adequately covers the main intent and prerequisite. Could note that the old window's elements may become invalid, but overall complete for the tool's 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% with the parameter description already linking to 'get_window_handles'. The description reinforces this by restating the source of the handle, adding clarity.
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?
Clearly states the verb 'Switch focus' and the resource 'window by its handle'. Distinguishes from sibling tools like 'switch_to_window_by_title' which uses a title instead of handle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the prerequisite to call 'get_window_handles' first to obtain the handle. However, it does not explicitly state when not to use this tool or compare with alternatives like 'switch_to_window_by_title'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a key behavioral constraint not provided by annotations: 'Simulates a real mouse event at screen coordinates, so the target window must be visible and in the foreground.' This is valuable beyond the 'destructiveHint: false' annotation. It could mention other side effects (e.g., mouse movement) but covers the most critical operational requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the core action and purpose, then use cases, then a constraint. Every sentence is informative and there is no superfluous text. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema), the description covers main use cases but lacks details on return values, error conditions, and edge cases such as what happens when both elementId and coordinates are provided or how interClickDelayMs works. It is adequate but incomplete for a tool with many configurable options.
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 63%, so baseline is 3. The description provides a high-level summary of parameters (modifier keys, multiple clicks, duration) but does not add specific syntax, validation rules, or interaction behavior beyond what the schema provides. It does not detail parameter priority (elementId vs x+y) or the meaning of interClickDelayMs.
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 ('Perform a click'), the targets ('element or absolute screen coordinates'), and variations ('modifier keys, multiple clicks, custom duration'). It lists specific use cases (right-click, double-click, Ctrl+click, coordinate-based clicks) which distinguish it from the simpler sibling 'click_element'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for right-click, double-click, Ctrl+click, or coordinate-based clicks', providing clear context for when this tool is appropriate. However, it does not explicitly state when to use the simpler 'click_element' instead, so it lacks explicit exclusion alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'destructiveHint: false' already indicates this is a non-destructive operation. The description adds the behavioral detail that the user must provide the session ID, but does not disclose what happens if the session doesn't exist, whether attachment changes session state, or if multiple attachments are supported. With the annotation covering the safety aspect, the description adds moderate value by clarifying the user interaction requirement.
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 two sentences long with no wasted words. It front-loads the core action and follows with clear user instructions. The only minor inefficiency is slight repetition between the two sentences regarding the session ID, but overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (1 parameter, no output schema, no nested objects), the description covers the essential purpose and usage context. It doesn't explain return values or error conditions, but for a straightforward attachment operation with rich schema coverage, completeness is adequate for an AI agent to use 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?
Schema coverage is 100% with only one parameter, and the schema itself includes a comprehensive description for 'sessionId' ('The Appium session ID to attach to (get from Appium Inspector or server logs)'). The tool description repeats this effectively but does not add new meaning beyond the schema, so baseline 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 'Attach to an existing Appium session by session ID', which is a specific verb ('Attach') and resource ('existing Appium session'). It distinguishes itself from sibling tools like 'create_session' (which creates new sessions) and 'delete_session' (which terminates sessions), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to 'Ask the user to provide the session ID' and explains where to find it ('visible in Appium Inspector or in the Appium server logs next to the session creation event'). This provides clear guidance on when to use this tool - only when a session already exists and the user can supply its ID, distinguishing it from 'create_session' which does not require an existing session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnlyHint=true. The description adds valuable behavioral detail by specifying the exact return patterns: 'NATIVE_APP' for the UIA tree and 'WEBVIEW_<id>' for webviews, enhancing transparency beyond 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 a single, focused sentence that efficiently communicates the purpose and return format. While slightly more structure (e.g., separate sentence for return details) could help, there is no waste.
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 parameters, no output schema, and a simple behavior, the description is complete. It covers what the tool does and what it returns. It could mention that this requires an active session (implied by tool context), but that is a minor gap.
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?
There are zero parameters and schema coverage is 100%, so the description does not need to add param info. The baseline for no parameters is 4, and the description appropriately does not invent unnecessary details.
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 lists all available contexts, defining the verb 'List' and the resource 'contexts'. It distinguishes from sibling tools like get_current_context (single) and set_context (mutation) by specifying it returns all contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this to see available contexts before potentially switching with set_context. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives like get_current_context for the current single context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, and the description is consistent with that. However, the description adds no additional behavioral context beyond the annotation (e.g., whether the check requires authorization, whether it incurs cost, or what happens if no session exists). The annotation already covers the safety profile, so the description contributes minimally.
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?
Single sentence, concise and front-loaded. Every word is functional with no redundancy. Highly 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?
For a zero-parameter, read-only status check with no output schema, the description is complete enough. It tells the agent exactly what the tool does. No additional context about return values or behavior is strictly necessary given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100% (empty properties). The description does not need to add parameter info. Baseline 4 for zero parameters is appropriate; the description is sufficient.
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 clearly states verb 'Check', resource 'session status', and scope 'currently active in this MCP server instance'. It effectively distinguishes from sibling session tools like create_session, attach_session, and delete_session by indicating it is a status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While the purpose is clear, the description does not provide context about prerequisites, conditions for calling, or when to avoid it. Implied usage is straightforward but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description correctly aligns with a read-only operation. It adds valuable behavioral context: 'No external API key required' and 'DPI-aware coordinate mapping' for click interactions. This goes beyond the annotation and informs the agent about key characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence states the primary action and return value. The second adds two distinct benefits. No redundant or extraneous information. The structure is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, readOnly annotations, and no output schema, the description covers the core functionality and key features (DPI mapping, no API key). It does not specify the return format or error handling, but given the context, these are minor omissions. The description is sufficiently complete for an agent to understand when and how to use the 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?
The schema description for 'prompt' is generic ('Question or instruction about the screenshot'). The tool description enriches it by explaining that for coordinate queries, 'the agent will return DPI-corrected screen coordinates'. This adds specific meaning, helping the agent understand how to use the parameter effectively.
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 ('Take a screenshot and return it') and the purpose ('for visual analysis'). It distinguishes itself from siblings like 'find_by_vision' by emphasizing that the agent performs the analysis, not the tool. The mention of 'no external API key required' further differentiates it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for visual analysis but does not explicitly state when to use this tool versus alternatives (e.g., 'find_by_vision' for element detection or 'start_recording_screen' for video). No guidance on when not to use it or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, lowering the bar. The description adds valuable behavioral context: it takes a screenshot, delegates to an external model, and requires specific API keys. It discloses the external dependency and authentication needs beyond what annotations provide, without contradicting 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?
Three sentences, each purposeful: first states the action, second gives usage guidance, third lists prerequisites. No fluff or redundancy. Information is front-loaded with the tool's purpose.
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 covers purpose, usage context, and prerequisites. Since there is no output schema, the return behavior is partially covered by the responseFormat parameter's schema description, so the tool description need not repeat it. Minor gaps like potential errors or rate limits exist, but given the rich schema, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains each parameter's meaning, including the API key mapping for 'model'. The description adds no new parameter semantics; it just repeats the API key information already present. Thus the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 function: 'Take a screenshot and delegate visual analysis to an external vision model, returning the result.' It uses a specific verb and resource, and explicitly distinguishes itself from alternatives with 'Use when visual analysis should be performed by a separate model rather than by the calling agent.' This differentiates it from sibling tools like find_element or analyze_screen.
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 contextual guidance by specifying when to use: 'Use when visual analysis should be performed by a separate model rather than by the calling agent.' It also lists required API key prerequisites. However, it does not explicitly name alternative tools or state when not to use it, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'readOnlyHint: true' already signals that this tool does not modify the UI. The description adds value by scoping behavior to a parent subtree and recommending post-interaction actions, but does not elaborate on whether the tool can return multiple elements, how it handles missing elements, or performance considerations. Since the annotation covers the safety profile, a 3 is appropriate.
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 at three sentences with no wasted words. It front-loads the core purpose, immediately provides usage context, and delivers actionable guidance in a structured numbered list. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter schema covers all details and an output schema does not exist (so return value is implicitly an element), the description is nearly complete. It misses a brief note on what happens when no child is found (error vs null), but for a scoped lookup tool with full schema coverage, it 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter (e.g., 'strategy' enum values are explained in detail in the schema). The description focuses on strategy ordering and usage, not on parameter format or constraints.
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 finds a child element within a known parent's subtree. It explicitly distinguishes this from sibling tools like 'find_element' (unscoped) and 'find_elements' (multiple results) by emphasizing the scoping to a parent element.
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 states when to use this tool ('when the same selector exists in multiple parts of the UI') and provides a prioritized strategy order for reliable automation (accessibility id > name > xpath > other). It also advises to call 'get_element_info' after interaction to capture the best locator, offering clear best-practice guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds the UIA Selection pattern mechanism and that the return is a JSON array of element IDs. This informs the agent about underlying behavior and return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences – the first states the core action and resource, the second describes the return format. No wasted words and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool (1 param, no output schema), the description adequately covers purpose, method (UIA Selection pattern), and return format. It does not elaborate on error conditions or multi-select container definition, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description ('Element ID returned by find_element'). The description adds no additional semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (Get), the specific resource (all currently selected items in a multi-select container), and distinguishes from siblings like get_selected_item (singular) and select_item/add_to_selection.
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?
Context is explicit: the tool is for multi-select containers. It implies the usage scenario but does not provide explicit when-not-to-use or alternative tools, though the sibling list makes it inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it retrieves 'window handles for the current session,' but does not elaborate on return format, ordering, or edge cases (e.g., no windows). Since annotations cover the primary behavioral aspect, a 3 is appropriate.
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 consists of two succinct sentences that front-load the core action and then provide usage guidance. Every word serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description covers the purpose and usage context adequately. It could mention that it returns a list of handles, but given the tool's simplicity and the annotations, this is a minor omission.
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?
There are zero parameters and schema description coverage is 100% (trivially). With no parameters to explain, a baseline of 4 is warranted. The description does not need to add parameter semantics and does not attempt to.
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 'Get all available window handles for the current session.' It specifies the verb (get), the resource (window handles), and the scope (all available, current session). This distinguishes it from siblings like get_current_window_handle and switch_to_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage hint: 'Use when the app has multiple windows.' This provides clear context for when to invoke the tool. It does not explicitly mention when not to use or name alternatives, but the sibling list contains get_current_window_handle for single handle retrieval, which serves as an implicit contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context (whole-window operation, no elementId needed) beyond the idempotentHint annotation, but does not disclose any side effects, return value, or state changes. The annotation already indicates safe repeated calls, but behavioral details are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and resource, and includes a parenthetical clarification. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, idempotent annotation), the description is adequate. It explains the key distinction from minimize_window, which is the most important context. Could briefly mention that the window is minimized to the taskbar or how to restore, but not essential.
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 zero parameters, the description does not need to explain them, but it adds value by clarifying why no elementId is required, contrasting with a sibling tool. This provides semantic context beyond the empty 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?
Clearly states the verb 'minimize' and the resource 'current session's root window'. Explicitly distinguishes from sibling 'minimize_window' by noting it does not require an elementId, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a direct comparison with 'minimize_window' by highlighting the lack of elementId requirement, which helps the agent choose between them. However, it does not elaborate on when to use the tool versus other window operations or general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral disclosure. It reveals the underlying mechanism (IHTMLWindow2.navigate via IE COM bridge) and key behaviors (no keyboard shortcut needed, no foreground requirement). It could improve by mentioning potential outcomes (e.g., success/failure handling, asynchronous behavior), but for a simple navigation the current detail 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?
Two sentences, each adding unique value. The first sentence is the action statement; the second provides critical usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the key constraint (IE window only) and the behavioral nuance (no foreground needed). It is complete enough for an agent to use correctly. Minor gap: does not describe what happens after navigation (e.g., page load wait).
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% with one parameter 'url' described as 'URL to navigate to'. The description restates this ('Navigate the current IE window to a URL') but adds no additional detail about format, validation, or protocol requirements. 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 action ('Navigate') and the resource ('current IE window to a URL'). It distinguishes from sibling tools like navigate_back and navigate_forward by specifying the target is a URL. The constraint 'Only supported when the active window is an IE window' further clarifies scope.
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 when to use this tool: to navigate without needing keyboard shortcuts or the window to be in the foreground. It also states the prerequisite (IE window active). However, it does not explicitly mention when not to use it or provide alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states the action and a required precondition, but does not disclose potential side effects (e.g., what happens if called when not in a frame) or error conditions. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences covering the action, prerequisite, and limitation. Every sentence adds value with no redundant or vague 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 the tool has no parameters, no output schema, and low complexity, the description covers the essential behavior and a key constraint (IE-only). It could mention what happens when called outside a frame, but overall it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is trivially 100%. With no parameters, the description is not required to add parameter information, and a baseline score of 4 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 the specific verb 'Switch back' and identifies the resource as 'top-level document', clearly distinguishing it from sibling tools like switch_to_frame and switch_to_parent_frame by stating it returns to the top level after a frame interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool is required ('before interacting with elements outside the frame') and includes a platform restriction ('Only supported in IE context'). It does not explicitly mention when not to use it, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows this is non-destructive. The description adds that it returns element ID strings in a JSON array, which goes beyond annotations but doesn't describe edge cases like no matches, multiple matches, or performance characteristics. With annotations covering the safety profile, a 3 is appropriate.
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 well-structured paragraph with clear strategy priority numbering. It's informative without being verbose. Minor deduction for lacking a line break before strategy list for better scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (2 params, both required, fully described) and readOnlyHint annotation, the description sufficiently covers usage intent and strategy selection. It lacks explicit mention of error behavior for invalid selectors or cases where no matches exist, but this is acceptable for a find operation.
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% coverage with detailed enum descriptions for strategy. The description adds value by providing a prioritized strategy list and practical guidance on when to use each, going beyond the enums to explain the 'why' behind each strategy choice.
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 finds UI elements matching a selector and returns a JSON array of element ID strings. It distinguishes itself from siblings like find_element (returns single element) and find_child_element (scoped to parent) by its generic search scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit strategy prioritization (accessibility id > name > xpath > other), tells when each strategy is appropriate, and directs users to call get_element_info after interacting with located elements to capture the best locator for test code. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by specifying the return values (LANDSCAPE or PORTRAIT). It does not contradict any annotations. While it doesn't disclose additional behavioral traits like auth needs or side effects, the annotation already covers the read-only nature, and the return clarification is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, containing only essential information. Every word serves a purpose with no 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 simplicity (no parameters, no output schema, annotations present), the description fully covers what the tool does and what it returns. It is complete for the agent to understand its purpose and outcome.
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 zero parameters and 100% schema description coverage, the baseline is 4. The description does not need to add parameter information since there are none. It correctly implies that no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current display orientation with specific possible values ('LANDSCAPE' or 'PORTRAIT'). It uses a specific verb ('get') and resource ('display orientation'), distinguishing it from sibling tools that deal with windows, elements, or other properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a simple query for orientation, but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. For a straightforward read-only tool, the implied usage is adequate, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that the result is an 'element ID' (not the element itself), providing useful behavioral context beyond the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word earns its place.
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 parameterless read operation with annotations covering safety, the description sufficiently explains the tool's purpose and return value (element ID). No output schema is needed as the description covers the output.
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?
There are zero parameters, and schema coverage is 100% (empty). The description does not need to add parameter info, and it correctly avoids redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'element ID of the current session's root window element', distinguishing it from sibling tools like 'get_active_element' or 'find_element'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the root window element's ID, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the extensive list of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses return format (true/false), supported element frameworks (UIA, Java Swing), and a key behavioral limitation (indeterminate returns false). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a note. The first sentence states the core purpose, the second clarifies scope and return, and the note adds a critical caveat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description fully covers what the tool does, its return value, supported element types, and a key limitation. The agent has all necessary information to use 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?
Schema coverage is 100% with one parameter elementId already described as 'Element ID returned by find_element'. The description adds no further meaning to the parameter beyond what the schema provides, so baseline 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 checks if a checkbox, radio button, or toggle is selected, specifying support for UIA and Java Swing elements. It distinguishes from siblings like is_element_displayed by focusing on selection state and includes a specific limitation about indeterminate states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when checking selection state but does not explicitly compare to alternatives like get_attribute or other is_* tools. It provides no when-not-to-use guidance, only a limitation about indeterminate checkboxes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, indicating the call is safe to repeat. The description adds the crucial behavioral detail that scrolling uses the UIA ScrollItem pattern and operates on a container. This is valuable context beyond the annotations. It doesn't specify behavior when the element is already visible, but idempotency implies no-op.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence delivers the core action and mechanism, the second provides usage context. Every sentence earns its place.
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, idempotent scroll action with no output schema, the description is fully sufficient. It covers what the tool does, how it works, and when to use it. No critical information 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?
Schema coverage is 100% with a clear description for elementId ('Element ID returned by find_element'). The tool description does not add any additional meaning about the parameter beyond what the schema already provides. Baseline 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 action ('Scroll a container'), the target ('given element'), the outcome ('becomes visible'), and the mechanism ('via the UIA ScrollItem pattern'). This distinguishes it from sibling tools like 'scroll' (generic scroll) or 'click_element' (which may require prior scrolling).
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 second sentence explicitly advises using the tool before clicking an element that may be outside the visible scroll area. This provides clear when-to-use guidance. While it doesn't list alternatives or when-not-to-use, the context is sufficiently clear for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false, so description carries the behavioral burden. The description discloses the restart behavior and the need to call stop_recording_screen. However, it does not mention whether the recording can be paused, what happens on errors (e.g., missing path permissions), or the format of returned data. A 4 is appropriate as it adds significant context beyond annotations but has minor gaps.
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 two sentences, which is concise and front-loaded with the core purpose. Every sentence adds value, though the second sentence could be slightly more direct about the stop call. No waste, but slightly more context on restart could be merged.
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?
With 9 parameters, no output schema, and a 'stop' sibling, the description explains the lifecycle (start/stop/restart) but lacks detail on edge cases (e.g., concurrent recordings, permission errors). It is sufficient for typical use but not exhaustive. A 4 reflects good coverage given the complexity.
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 does not add extra meaning to the parameters beyond what their schema descriptions already provide. It lists nothing about parameter usage, so no extra credit is earned.
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 identifies the tool as starting an FFmpeg-based screen recording, distinguishes it from stop_recording_screen, and mentions the default restart behavior. The verb 'start' and resource 'recording' are explicit and unambiguous.
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 when to use this tool (start recording) and when to use the sibling stop_recording_screen (end and retrieve video). It also clearly states the default restart behavior if a recording is already running, guiding the agent on usage flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false. The description adds important behavioral details: it injects an agent into the JVM and changes element finding from UIA to Java class/accessible names. This goes beyond what annotations offer, though it could mention prerequisites or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The first sentence states the core action; the second provides usage timing and behavior change. Information is front-loaded and efficient.
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 one parameter, no output schema, and many sibling tools, the description covers purpose, usage timing, and behavioral change. It adequately sets expectations but could be slightly richer (e.g., error handling or prerequisite JVM).
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 single parameter jdkPath with its description. The tool description adds: 'Overrides the jdkPath session capability,' which clarifies how it interacts with session-level configuration. This adds meaningful context beyond the schema, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Inject' and the resource 'Java accessibility agent into the JVM owning the current session window.' It specifies the precise condition for use (after creating a session without javaSwing), making it easy to distinguish from siblings like attach_session and create_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('after creating a session...when javaSwing was NOT set') and explains the behavioral consequence ('element finding will use Java class names...instead of UIA'). It does not explicitly list when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation (already indicating destructive behavior), the description adds two critical behavioral traits: the folder is deleted recursively by default, and the operation requires a specific insecure feature to be enabled. These details help the agent understand preconditions and default 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?
Two sentences, front-loaded with the main action, no extraneous text. Every sentence adds value: the first states the action and default behavior, the second states a necessary precondition.
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 adequately covers purpose, prerequisite, and default behavior for a simple delete operation with two well-documented parameters. It does not mention the return value (e.g., success indication), but no output schema exists, so this is a minor gap for complete agent usage.
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 both parameters, so the baseline is 3. The description reiterates the recursive default but does not add additional semantic meaning beyond what the schema already provides for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Delete', the resource 'folder', and specifies the scope 'on the machine running the driver'. It also notes the recursive default behavior, which distinguishes it from delete_file, a sibling tool that deletes a single file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite that the 'modify_fs' insecure feature must be enabled on the Appium server, providing clear usage context. However, it does not explicitly contrast with alternatives or state when not to use this tool, though the sibling list includes delete_file which hints at the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description warns 'Runs with the same privileges as the driver process — treat as unrestricted code execution.' This adds critical behavioral context about security and impact, fully satisfying transparency requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three efficient sentences: action, use cases, and security caveat. Every sentence adds value with no redundancy or irrelevant detail.
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 single-parameter tool without output schema, the description covers purpose, use context, session persistence, privileges, and examples. A minor gap is not describing typical output (e.g., script stdout/errors), but this is expected from raw PowerShell execution.
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?
Only one parameter 'script' exists, and its schema description ('PowerShell script or command to execute') already provides full meaning. The tool's description adds no additional parameter-level detail, resulting in baseline 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 explicitly states the tool runs raw PowerShell scripts on the machine via a persistent session, with examples (registry edits, service control, file inspection). It clearly distinguishes from sibling tools which are specialized UI and browser automation commands.
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 says 'Use for arbitrary automation not covered by another tool', giving direct guidance on when to select this tool. It implies not to use it when a dedicated tool exists, though it does not explicitly list exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'readOnlyHint' annotation is true, which matches the safe, non-destructive nature of getting a handle. The description adds value by specifying the return type (hex HWND string) and an example, going beyond the annotation. With only 0 parameters and no complex behavior, this is sufficient disclosure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 16 words. It is front-loaded with the action and includes an example. Every word is necessary, and there is zero wasted text. This is an excellent example of conciseness.
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 that only retrieves a string handle, the description is complete enough. There is no output schema, but the description explicitly states the format and example, compensating for the lack of schema. A score of 4 accounts for the adequate coverage while noting that a more explicit mention of possible error cases (e.g., if no window is active) would push it to 5.
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?
There are 0 parameters with 100% schema coverage, so the baseline is 3. The description adds meaning by explaining that the output is a hex HWND string with example format. This provides practical information that the schema alone does not (since the schema is empty). Therefore, a 4 is justified for adding clear description of the return value format.
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 ('Get the handle') and a clear resource ('current window'). It explicitly states the return format as a hex HWND string with an example, making the tool's purpose unmistakable. It does not need to distinguish from siblings, as no sibling retrieves a single window handle without switching.
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 this is for obtaining a unique identifier of the current active window, which helps the agent understand when to call it (e.g., before window operations). No explicit when-not-to-use or alternatives are given, but the context of sibling tools like 'get_window_handles' and 'get_windows' provides implicit differentiation. A score of 4 is appropriate since usage is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly matches the readOnlyHint annotation (true) by describing a non-destructive action. It adds behavioral context beyond annotations: the output format (base64 PNG) and the browser compatibility limitation (IE). This transparency is strong, though it could mention if the screenshot includes element visibility conditions or timeouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences, zero redundancy. Every sentence provides unique value: the first states the core action and output, the second states a limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, clear annotations), the description is nearly complete. It explains what the tool does, the output format, and a key limitation. It only lacks mention of potential prerequisites (e.g., element must be located first) or behavior for hidden elements, which are minor gaps.
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%, with the parameter 'elementId' already described as 'Element ID returned by find_element'. The description adds no additional parameter details but also does not need to, given the schema's clarity. A minor deduction because the description could clarify that the element must be visible or scrolled into view.
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 cropped to a single element and returns it as base64 PNG. It distinguishes itself from other screenshot tools in sibling list by specifying 'element' cropping. The verb 'Take' and resource 'screenshot cropped to a single element' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear exclusion: 'Not supported in IE context.' This provides context for when not to use the tool. However, it does not explicitly mention when to use this over other screenshot tools (like full-page screenshots) or provide alternatives for IE context. The constraint is clear but partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation. The description adds valuable context by listing the specific data returned (bounds, working area, device name, primary status). It does not contradict the annotation and gives sufficient transparency for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb 'List' and packs all relevant details without any redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description covers the main output fields and implies a list/array return. It could be slightly more explicit about the return type, but for a basic enumeration tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no meaningful information. The description still conveys the tool's scope (listing monitors) without needing to explain parameter meaning, matching the baseline of 4 for parameterless tools.
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 'List' and clearly identifies the resource ('all connected monitors') plus the exact information provided (bounds, working area, device name, primary display). It is distinct from sibling tools, none of which target monitor enumeration.
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 clearly implies usage when monitor information is needed, and there are no sibling tools that serve a similar purpose. However, it does not explicitly state when to use it versus alternatives or provide exclusions, though alternatives are not evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint=true, and the description aligns by stating it is a read-only walk of the accessibility tree. It adds significant behavioral context beyond annotations: details that it bypasses UIA, walks IAccessible, and returns simple children without HWND. The only minor gap is not explicitly stating it is non-destructive or whether it may have side effects, but overall it is thorough.
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 paragraph of moderate length, front-loaded with the main purpose and fallback advice. Every sentence contributes necessary technical detail and guidance. It could potentially be slightly more concise by removing some redundant technical explanation, but it is well-structured for an agent.
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 (handling legacy accessibility), one required parameter, high schema coverage, and lack of output schema, the description provides all necessary context: the exact technology, expected return structure, and failure fallback. It does not need to explain return values because the JSON field list is given. The agent can fully understand when and how to use this tool.
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 adds context about the elementId parameter (window handle to walk via IAccessible) but does not provide additional constraints like valid formats or examples beyond the schema. It meets the baseline without 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 clearly states the tool is a fallback for legacy WinForms/ActiveX controls lacking UIA children. It specifies the exact technology (IAccessible/MSAA), the scenario (hand-written MSAA support exposing rows/cells as simple children), and distinguishes itself from standard UI Automation tools. This verb+resource+scope is highly specific and differentiates from siblings like get_page_source and find_element.
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 advises verifying with get_page_source/Inspect.exe first, providing a clear prerequisite. It also gives a when-not-to-use guideline: if supported is false or root has zero children, fall back to find_by_vision/analyze_screen and advanced_click. This directly helps the agent decide between tools, offering both context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by explaining the tool is low-level and raw, requiring careful construction of action sequences. However, it does not clarify error behavior, prerequisites (e.g., an active session), or the fact that actions may have side effects beyond destructiveness.
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 long, front-loads the core purpose, and immediately provides usage differentiation. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single complex parameter and lack of output schema, the description plus schema provide adequate context for an agent to decide when to use the tool and how to structure input. It could be improved by noting the need for an existing session or error handling, but overall it is sufficient for selection and 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 input schema already includes a description for the sole parameter 'actions' with a link to the full W3C spec (100% coverage). The tool description does not add additional meaning or clarifications about the parameter beyond what the schema provides, so a 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 it performs a raw W3C WebDriver Actions sequence for pointer, key, and wheel input sources. It explicitly contrasts itself as a lower-level alternative to advanced_click, hover, scroll, and send_keys, making its purpose distinct 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 provides explicit when-to-use guidance: 'use only when you need multi-source synchronized input (e.g. a key held down during a pointer drag) that those higher-level tools cannot express.' It also names the alternatives that should be preferred for simpler cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint: false (non-destructive). The description adds significant behavioral context: it simulates real OS-level key events, requires window focus, and cannot target specific elements. This goes beyond the annotation, openly disclosing limitations and behavior. No contradictions found. The high bar for transparency is met, though no return format or error conditions are described, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences, each packed with essential information. The first sentence states the action types, the second explains the behavioral constraint (focus requirement), and the third lists example use cases. No redundant words, 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?
Given the tool has no output schema and 2 parameters with full schema coverage, the description is well-matched. It explains the core mechanics, constraints, and typical use cases. It does not detail error scenarios or real-world caveats (e.g., special character handling beyond unicode), but for a simple input tool, this is sufficient. Lacks only a note on return value (maybe null or success flag), but not critical.
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 baseline is 3. The description adds meaning by explaining the action types (pause, text, virtual key code) and notes that 'down: true/false' controls key press/release behavior, which the schema's description for 'down' is limited. It also mentions Unicode support in text, complementing the forceUnicode parameter. This lifts the score to 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 sends keyboard input, specifying three action types (pause, text, virtual key code). It also distinguishes from sibling tools that target elements or windows, by explicitly noting it sends keys to whatever window has focus, not a specific element. This makes the purpose specific and differentiates from other 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 for when to use this tool: for key combos, navigation keys, or typing into controls without addressable elements. It explicitly says the target must be focused and cannot target a specific element. However, it does not mention when not to use it (e.g., when an element is addressable, use click_element or set_value instead), so it loses a point for lacking explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the tool's behavior: it returns a string with specific format and explains what each possible value means. The annotation readOnlyHint=true is consistent with the read-only nature of the operation. The description adds significant value beyond the annotation by detailing the return values and their implications for element interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It is front-loaded with the purpose, immediately followed by specific return value details and usage guidance. Every sentence earns its place.
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 has no parameters, no output schema, and only a readOnlyHint annotation, the description provides complete context: what it does, what it returns, and when to use it. An agent has all necessary information to correctly invoke and interpret the result.
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 schema coverage is 100% (trivially). The description does not add parameter-level semantics because there are none. Per the scoring guidelines, baseline is 3 when schema coverage is high. The description's explanation of the output is valuable but falls under behavioral transparency rather than parameter semantics.
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: 'Get the current active context.' It specifies the two possible return values (NATIVE_APP and WEBVIEW_<id>) and explains their meanings. This distinguishes it from siblings like get_contexts (which likely returns all contexts) and set_context (which changes context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use the tool: 'Call this if unsure which context is active before interacting.' This provides clear guidance on its use case. It does not explicitly name alternatives, but the context is clear enough for an agent to decide when to invoke this versus other context-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds valuable behavioral details beyond annotations: it lists what properties are returned, explains selector priority, and gives a code example. No contradiction or missing behavioral traits for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five well-structured sentences: purpose, return list, usage instruction, selector priority, and a code example. Every sentence earns its place; no filler. Front-loaded with the main purpose.
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 only 1 param and no output schema, the description is complete. It explains return values, usage context, and even includes a practical coding tip. For a tool with 67 siblings, it clearly differentiates itself and covers all necessary information for an agent to use 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?
Schema coverage is 100% (elementId is documented as 'Element ID returned by find_element'), so baseline is 3. The description reinforces the parameter's role by stating to call after find_element, but does not add new semantic details beyond the schema. Minimal added 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 clearly states the tool retrieves UIA properties and selector suggestions, specifying the verb 'retrieve' and resource. It explicitly lists return values (Name, AutomationId, etc.) and differentiates from sibling tools by positioning it as the go-to after find_element for test automation.
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 when to use: 'ALWAYS call this after find_element when generating automated test code'. It provides the context for use and explains selector reliability order, giving clear guidance on when and how to apply the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation covers the read-only safety aspect, and the description adds valuable behavioral details such as including untitled windows and the structure of returned objects. It explains how the data can be used, which goes beyond 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?
Two concise sentences that front-load the core purpose, mention the return type, and give examples of usage. No redundant words or 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?
For a zero-parameter, no-output-schema tool, the description covers essential information: what it returns, how to use the fields, and the specific use case for untitled windows. This is sufficient for an agent to select and invoke the 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?
The tool has zero parameters, and the schema is empty, so there is no parameter semantics to clarify. The description focuses on return values, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all visible windows including untitled ones, and specifies the return shape. It distinguishes itself from sibling tools like get_window_handles by mentioning the className and untitled support.
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 guidance on using the handle for switching via switch_to_window and using className to identify untitled windows. Though it doesn't explicitly name alternative tools, the practical use cases are well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation already indicates the operation can be safely repeated. The description adds value by explaining the operation's scope (root window) and the key difference from maximize_window (no elementId required), which helps the agent understand behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately communicates the action, scope, and key differentiator. Every word serves a purpose, and the parenthetical clarification is efficient. No wasted text.
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 has no parameters, no output schema, and the idempotentHint annotation covers idempotency, the description is complete. It fully explains what the tool does, its scope, and how it differs from a similar sibling. No gaps remain.
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% with 0 parameters, so no parameter documentation is needed. The description explicitly clarifies that no elementId is required, which adds meaningful context beyond the empty schema. Baseline is 4 for no params, and the description enhances it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maximizes the current session's root window, uses a specific verb ('maximize'), and distinguishes itself from the sibling maximize_window by explicitly noting it operates on the whole window without needing an elementId. This resolves ambiguity in a crowded sibling group.
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 when to use this tool (for whole-window maximize without an elementId) and contrasts it with maximize_window, which requires an elementId. However, it does not explicitly state when NOT to use it or mention alternatives beyond the one sibling. The context about elementId provides clear usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavioral trait: it is only supported in IE context and behaves like switch_to_default_content. This provides useful context beyond the bare action, though it doesn't mention error cases or effects in non-IE contexts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose and followed by the key limitation. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description sufficiently covers what the tool does and its limitation. It is complete for its simplicity, making the tool's behavior clear to an agent.
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 input schema is empty. The description adds no parameter information, but none is needed. Baseline 4 is appropriate given the description is not required to explain parameters that don't exist.
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 ('Switch context to the parent frame') and specifies the target (current frame's parent). It distinguishes itself from sibling tools like switch_to_frame and switch_to_default_content by noting the IE-only behavior and equivalence to switch_to_default_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the only supported context ('Only supported in IE context') and mentions behavioral equivalence to switch_to_default_content there, giving a clear constraint and a reference alternative. It does not explicitly say when not to use it, but the IE limitation implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool ends the session and closes the app, which is the core destructive behavior. While annotations already declare destructiveHint=true, the description adds important context about the autonomous use prohibition, which is beyond what annotations provide.
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 two sentences: the first describes what the tool does, and the second provides usage guidelines. It is front-loaded and efficient, though the second sentence could be slightly more concise.
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 no parameters, no output schema, and annotations providing destructiveness, the description is complete. It does not need to explain return values or parameters, and it provides all necessary behavioral and usage context.
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?
There are no parameters, so the description naturally has nothing to add about parameters. With 100% schema coverage (trivially), a baseline of 4 applies due to no param info being needed.
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 ends the current Appium session and closes the app, using specific verbs ('End', 'close') and resources ('Appium session', 'app'). It distinguishes itself from siblings by its destructive nature, unlike many other session or element 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 provides explicit guidelines: 'Only call this when the user explicitly asks to stop or end the session' and 'Never call autonomously — always confirm with the user before terminating.' This clearly tells the agent when to use and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It accurately indicates a safe, non-destructive read operation (navigating history). The only missing detail is what happens if there is no forward history (e.g., throws error or does nothing), but this is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, complete sentence that efficiently conveys the purpose and behavior with no extraneous words. It is perfectly front-loaded and earns its place.
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 tool is simple (no parameters, no output schema) and the description fully covers its purpose and basic behavior. No additional context is necessary for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so no additional parameter documentation is needed. The description is sufficient and adds no redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'navigate forward' and the resource 'current window's history', and distinguishes itself from the sibling 'navigate_back' by specifying direction. It even includes the keyboard shortcut Alt+Right for clarity.
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 this is for moving forward in browser/session history, which is clear context. However, it does not explicitly state when not to use it (e.g., no forward history available) or mention the sibling 'navigate_back' as an alternative. This is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the 'readOnlyHint' annotation by specifying the IE-only limitation and the automatic IE mode activation. It does not contradict annotations. A slight deduction for not stating what happens if called when not on an IE window (e.g., error or empty result), but overall good disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action in the first sentence and essential supporting context in the second. No superfluous words, effectively 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?
Given the tool's simplicity (no parameters, no output schema), the description covers all necessary context: what it does, when it works, and how to prepare the active window. It references relevant sibling tools for setup, making it sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the input schema provides complete coverage. The description appropriately adds no parameter details. Baseline 4 is warranted as the description does not need to compensate for any missing schema information.
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 gets the current page URL, using the verb 'get' and the resource 'current page URL'. It distinguishes itself from siblings like 'get_window_title' or 'set_url' by specifying the unique constraint of IE window support.
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 states when to use the tool ('when the active window is an IE window') and provides guidance on how to enable that condition via sibling tools 'switch_to_window' / 'switch_to_window_by_title'. This effectively tells the agent when to and when not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares it waits for an element and returns an element ID, consistent with readOnlyHint annotation. It does not contradict annotations. It adds value by describing the configurable timeout and poll interval, and the retry behavior is implied. Could be improved by explicitly stating what happens on timeout (e.g., throws exception), but it is already adequate.
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 short paragraphs and a numbered list. Every sentence serves a purpose: capturing the core action, outlining typical use cases, defining strategy preferences, and suggesting a follow-up call. No wasted words.
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 (waiting for a UI element with configurable timeout and multiple strategies) and the presence of annotations and full schema coverage, the description is complete. It explains what the tool does, when to use it, what strategies to prefer, and how to proceed after use. No gaps remain.
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 each parameter is already well-documented. The description goes beyond by providing a preferred strategy order and the context for each strategy (e.g., 'accessibility id' is most stable). This adds practical guidance not present in 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 clearly states the tool's purpose: 'Wait for a UI element to appear within a configurable timeout, then return its element ID.' It also provides specific use cases (dialog opens, page transitions, loading spinners), distinguishing it from sibling tools like find_element or click_element.
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 includes explicit guidance on when to use the tool and how to select a strategy: 'Preferred strategy order for reliable automation' with a numbered list. It also advises calling get_element_info after interacting with the element, which helps the agent decide follow-up actions. This clearly differentiates from siblings and provides decision rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by clarifying the tool returns an XML tree and is intended as a 'source of truth' for UI state. This adds meaningful behavioral context, though it does not detail any potential performance overhead or size limits of the XML output. The annotation supports the safe-read nature, and the description reinforces it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just three sentences, each sentence carrying essential information: what the tool does, when to use it, and what to do with the result. There is no wasted text, and the key directive ('use as the source of truth') 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?
Given zero parameters, a clear readOnlyHint annotation, and a definition that explicitly describes the return value's role and how to use it, the description is fully complete. It provides all context needed for correct agent invocation without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics because the input schema has no parameters, making this a baseline 4. However, it strongly clarifies the output's semantic role (source of truth, to discover Names and AutomationIds), which effectively compensates for the missing output schema. This is excellent context for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the XML representation of the current UIA element tree, using specific verbs ('Get', 'Inspect') and naming the resource ('current UIA element tree'). It distinguishes itself from sibling tools like find_element or get_element_info by describing a broader, structural snapshot of the entire UI state.
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 tells the agent when to use this tool: after a UI change (navigation, dialog, window switch) or whenever unsure about the current state. It also provides a clear directive to inspect the result for element Names and AutomationIds, making the usage guidance actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the single annotation (destructiveHint: false). It explains that injection is automatic for both .NET Framework and CoreCLR, works only on an already-running process, and is needed for specific UI libraries. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding value. Front-loaded with the action, then usage context, target apps, and limitations. No redundant or unnecessary words.
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 zero parameters, no output schema, and only one annotation, the description is complete. It covers purpose, usage timing, prerequisites, target applications, and technical constraints. An agent can fully understand when and why to use 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?
The input schema has zero parameters, so baseline is 4. The description does not need to add parameter semantics, and it provides sufficient context about the tool's operation without needing parameter details.
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 ('inject') and resource ('.NET bridge') with clear context ('CLR process owning the current session window'). It also states when to use it (after session creation when dotnetBridge was not set), distinguishing it from sibling tools like create_session and attach_session.
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?
Explicitly says 'Use this after creating a session... when dotnetBridge was NOT set'. Also states 'Only works on an already-running process — there is no launch-time injection path' and describes the target app types (WinForms/WPF with custom-drawn controls). This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds specific behavioral context: it releases all held keys/buttons from a previous perform_actions call, which is valuable beyond the annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action. Every sentence adds essential information with no waste. Highly concise and well-structured.
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 has no parameters, annotations covering idempotency and destructiveness, and no output schema, the description is fully complete. It explains the purpose, when to use, and the triggering condition. 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?
There are zero parameters, so the schema coverage is 100% by default. The description does not need to add parameter details. According to the rubric, baseline for 0 parameters is 4, and the description meets that standard.
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 releases all keys and pointer buttons held down from a prior perform_actions call. It uses a specific verb ('release') and resource ('keys and pointer buttons'), and distinguishes well from sibling input tools like perform_actions or send_keys.
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 advises to call this tool to reset input state if perform_actions left keys/buttons stuck down, especially after an error. It gives both the context of use and the condition that triggers the need, making it clear when to use and when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![windows2-mcp MCP server](https://glama.ai/mcp/servers/verisoft-ai/windows2-mcp/badges/card.svg)](https://glama.ai/mcp/servers/verisoft-ai/windows2-mcp)

Score Badge

Copy to your README.md:

[![windows2-mcp MCP server](https://glama.ai/mcp/servers/verisoft-ai/windows2-mcp/badges/score.svg)](https://glama.ai/mcp/servers/verisoft-ai/windows2-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/verisoft-ai/windows2-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server