Touchpoint

by Touchpoint-Labs

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., click vs. action, find vs. elements). There is slight overlap between find and elements, but descriptions clarify their different use cases.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., activate_window, set_value, wait_for_app). No mixing of conventions.
Tool Count5/5
20 tools is well-scoped for UI automation. Each tool serves a clear need without being excessive or too few.
Completeness4/5
Covers core UI interactions (click, type, scroll, find, wait, screenshots). Minor gaps exist, such as no explicit launch app tool, but the surface is largely complete for accessibility automation.
Average 4.2/5 across 20 of 20 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on June 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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.
View related servers

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 must cover behavioral traits. It only says 'Close a window' without disclosing safety, error handling, or prerequisites beyond the ID. This is insufficient for an agent to understand side effects or potential issues.
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 and a parameter line. No wasted words; the purpose is front-loaded. This is ideal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of annotations, the description omits important context such as return values (though output schema exists), error behavior, and confirmation status. This is insufficient for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning to the parameter 'window_id' beyond the schema's title, stating 'The window ID to close.' With 0% schema description coverage, the description should compensate but does not provide format, source, or validation details.
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 'Close a window' with a specific verb and resource. It distinguishes from sibling tools like minimize_window or move_window. However, it does not elaborate on the exact behavior (e.g., confirmation, saving state), so it loses a point for lack of specificity.
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 advises using windows() to get the window ID first, providing a prerequisite. However, it does not specify when to use this tool over alternatives like minimize_window or close via other means, leaving some ambiguity.
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?
Without annotations, the description carries the burden of transparency. It only states the basic action, omitting details like whether the element must be focusable, side effects, or failure modes. The minimal description does not compensate for the lack of 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, consisting of two short sentences. Every part is functional: the first sentence states the purpose, and the second explains the parameter. No 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 (one required parameter) and the existence of an output schema, the description is partially complete. However, it lacks details on boundary cases (e.g., element not found) and behavioral aspects, making it merely adequate for a basic 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 zero coverage for parameter descriptions. The tool's description adds a brief explanation of the 'element_id' parameter ('The element ID to focus'), providing minimal semantics beyond the schema's title and type. This is a marginal improvement but still basic.
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 'Move keyboard focus' and the target 'element', using a specific verb and resource. It effectively distinguishes the tool from siblings like 'click' and 'type_text', which perform 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use the tool versus alternatives, nor does it mention any prerequisites or exclusions. This leaves the agent without context for appropriate invocation.
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 the full burden. It only states the action without detailing side effects, permissions needed, or behavior on failure. For a simple tool, minimal transparency is given.
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 at three short sentences plus argument explanations. The main purpose is front-loaded in the first sentence, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 parameters and no nested objects. The description covers prerequisites (finding window ID) but omits coordinate system details, error handling, or any output schema explanation. It is partially complete for a basic 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 'Args' section adds meaning to parameters beyond their names, e.g., explaining x and y as new top-left corner positions. However, it lacks details like coordinate system (screen vs. window), units, or bounds, leaving some ambiguity. With 0% schema description coverage, this is adequate but not comprehensive.
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 'Move a window to a new screen position' with a specific verb and resource. However, it does not specify the coordinate system (e.g., absolute screen coordinates), which would improve precision.
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?
Provides a prerequisite (use windows() to find window ID) but lacks guidance on when to use this tool versus alternatives like resize_window or focus. No exclusions or when-not-to-use are mentioned.
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 explains the behavioral difference between probe=true and probe=false (initialization vs. side-effect-free snapshot), which is good. However, it does not disclose other behavioral traits like potential impacts, authentication needs, or error conditions. Since no annotations are provided, the description carries the full burden but still has 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 extremely concise: one sentence for purpose, then a structured arg description. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key aspects: main purpose, parameter semantics, and side-effect distinction. An output schema is present, so return values need not be described. It could be more complete by explaining what 'health' encompasses, but overall adequate given the 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?
Schema description coverage is 0%, but the description adds meaningful details about the 'probe' parameter: what true and false do. This significantly enhances understanding beyond the schema, which only shows type and default.
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 reports health of backend, input, CDP, and optional dependencies. This is a specific verb and resource, and it distinguishes from sibling tools which are all action-oriented (click, type, etc.).
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 or when not to use it. The description only explains the probe parameter but does not provide context about typical use cases 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?
No annotations are provided, so the description carries the burden. It does not disclose any behavioral traits such as side effects, permissions needed, or error conditions. For a simple resize operation, this is adequate but not outstanding.
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 very concise: three lines of text plus parameter list. No unnecessary words, and it front-loads the 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?
Given that an output schema exists (not shown but indicated), the description covers the essential info: what it does, parameters with units, and a prerequisite. It does not discuss constraints or return values, but those are handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by specifying 'in pixels' for width and height, and clarifying that window_id is the target. This goes beyond the schema titles.
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 'Resize a window' with verb and resource. While it doesn't explicitly differentiate from siblings like move_window or fullscreen_window, the action is distinct enough.
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 helpful prerequisite: use windows() to find the window ID. However, it does not mention when not to use this tool or suggest alternatives among siblings.
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. It discloses high-level behavior (capture and return image) but omits details like image format, permissions, blocking behavior, or error conditions. This leaves significant gaps for an AI agent.
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 with a clear intro and a well-organized parameter list. Every sentence adds value, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers the tool's basic purpose and parameters, but lacks details on return format, error handling, and prerequisites. It is adequate but not fully comprehensive.
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 0%, so the description must compensate. It explains each parameter's role (crop target, padding, monitor) but does not clarify precedence when multiple crop parameters are specified, which could lead to ambiguity.
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 'Capture the screen and return an image' and explains behavior with no arguments vs. specifying a parameter to crop. It distinguishes from sibling tools like click or type_text by being the only capture tool.
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 guidance on how to use the tool: with no arguments captures full screen, with one parameter to crop. However, it does not explicitly compare with alternatives or state when not to use it, but given the unique purpose, the guidance is adequate.
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 only states the action without discussing error handling, value constraints, or whether the operation is destructive. Minimal behavioral 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 extremely concise with three short sentences, front-loading the purpose and listing parameters efficiently. 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 setter tool with 2 required parameters and an output schema (though not described), the description covers the essentials. It could mention return values or success behavior, but the complexity is low.
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 0%, so description adds value by clarifying that element_id is for a range element and value is a numeric. However, it does not provide additional details like accepted range or formatting, so meaning is limited.
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 sets a numeric value on range elements (slider, spinbox), which clearly distinguishes it from sibling tools like 'set_value' that handle text 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 implies usage for range elements by specifying 'slider, spinbox', giving context on when to use it. However, it does not explicitly state when not to use it or mention alternatives like 'set_value'.
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 provided, so description carries full burden. Describes two usage modes but does not mention whether move is instantaneous or has delays. Adequate but could be more transparent about async 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 efficient sentences plus clear 'Args' list. No redundant words. Front-loaded with main action.
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?
Covers main usage patterns and relationship with scroll(). Has output schema, so return not needed. Missing minor behavioral detail (e.g., if synchronous) but sufficient for a simple move action.
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 no descriptions (0% coverage). Description explains element_id (element target) and x,y as coordinate alternative. Adds meaning beyond 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?
Clear verb 'move' and resource 'mouse cursor', specifying two distinct modes (to an element or to screen coordinates). Distinguishes from siblings like 'click' and 'scroll'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use before scroll() for specific area scrolling. Also clarifies parameter usage (element_id vs x,y). Lacks explicit when-not-to-use but adequate.
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?
Discloses backend-dependent behavior (some backends expose aggregate descendant text). No annotations provided, but description misses error cases or side effects. Output schema exists, so return format is covered elsewhere.
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: first line states purpose, followed by two sentences on backend behavior and workflow. No redundant words, and information is 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 simple nature (one parameter) and existing output schema, the description covers workflow, backend variability, and parameter usage. Could mention error handling, but overall adequate.
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?
Single parameter 'element_id' has no schema description (0% coverage), but the tool description explains it fully: 'The element or container ID to read text from.' This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines the tool's function: returning text content from elements or containers. Specifies verb 'read' and resource 'text', and distinguishes from sibling tools like snapshot and select_text by focusing on reading 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage workflow: snapshot() then read_text(). Explains when to use with containers ('Pass a container ID from snapshot()'). Does not explicitly state when not to use or list alternatives, but 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, and the description does not disclose any behavioral traits beyond the basic action. It does not state what happens if the window is already in the requested fullscreen state 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 is concise with four sentences, using a clear docstring format. Every sentence is necessary and well-structured, 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 presence of an output schema (not shown), the description need not explain return values. It covers the essential steps and parameters. Minor omission: it could mention that the window must support fullscreen, but overall it's complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters (0% coverage), so the description fully compensates by explaining 'window_id: The window ID.' and 'fullscreen: True to enter fullscreen (default), False to exit.' This adds essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Enter or exit fullscreen for a window.' The verb 'Enter or exit' and the resource 'fullscreen for a window' are specific, and it distinguishes from sibling tools like move_window or resize_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 instructs to 'Use windows() to find the window ID first,' providing a clear prerequisite. It does not explicitly mention when not to use or alternatives, but the context is clear for this simple toggle.
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 explains the core behavior: single keys and combinations, with the detail that all keys in a combination are held together and released in reverse order. The repeat parameter is also clarified. However, it does not specify system-wide vs. focused-window behavior or error handling, which would add completeness.
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 no wasted words. It uses bullet-style formatting for examples and clearly separates single vs. combination keys. 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 tool's low complexity (2 simple parameters, no nested objects), the description covers the essential functionality well. It explains key behavior and parameter usage. Could optionally mention that the tool requires an active window, but the description is sufficiently complete for a key-press tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates. It explains the 'keys' parameter with clear examples of both single strings and list combinations, and clarifies that 'repeat' defaults to 1. This adds significant value beyond the bare 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 presses a key or key combination, with specific examples of single keys and combination lists. It effectively distinguishes from siblings like 'type_text' (typing strings) or 'click' (mouse 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 valid key examples and explains how combinations work (held together, reverse release), but does not explicitly guide when to use this tool vs. alternatives like 'type_text' for typing or 'focus' for activation. Implicit usage is clear but lacks explicit context for selection.
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 discloses polling behavior, timeout, and the 'gone' parameter effect, but lacks details like polling frequency or error handling. 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 well-structured with a brief overview followed by parameter documentation. Each sentence serves a purpose, and the key info is 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?
Everything essential for a simple wait tool is covered, but given an output schema exists, the description could mention return type (e.g., boolean success). Minor gap in completeness.
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?
Despite 0% schema description coverage, the description fully explains all three parameters: 'app' with examples, 'timeout' with default and unit, 'gone' with semantic meaning. Adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls for an application to appear or disappear, with specific verb 'wait for' and resource 'application'. It distinguishes itself from siblings like 'wait_for' and 'wait_for_window' by focusing on application lifecycle.
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 after launching or closing an application', providing direct context for when to invoke it. It doesn't explicitly exclude alternatives, but the context is clear enough for an agent to decide.
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?
Without annotations, the description indicates a non-destructive read operation. No additional behavioral details (e.g., permissions, rate limits) are given, but the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words, front-loading the purpose and usage guidance.
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 parameterless tool with an output schema, the description fully covers what the tool does and how to use its results.
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?
No parameters exist, and schema coverage is 100%. The description adds no parameter info, but the 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 tool lists all open windows and specifies the returned information (window IDs, titles, sizes, app names), distinguishing it from sibling tools like apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains how to use the output (scope find/elements queries or activate_window), providing clear context for usage, though it does not include 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?
No annotations provided, so description carries full burden. It describes what the tool does but does not disclose potential side effects, required permissions, or behavior on invalid input. Could be more transparent about mutability.
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?
7 lines, front-loaded with purpose, every sentence adds value. No fluff. Efficiently structured with Args section.
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?
Covers purpose and usage well, but does not reference the output schema or explain return values. Lacks error handling details. Given tool complexity, it's mostly complete but missing output documentation.
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?
Input schema has 0% description coverage, but description adds clear meanings: element_id is 'the element ID', action_name is 'exact action name from snapshot' with example. This compensates well for the schema gaps.
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 'Perform a raw accessibility action by exact name' and distinguishes from click, specifying it's for actions shown in snapshot. This is specific and contrasts well with siblings.
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 'Only call this when the element shows actions=[...] in snapshot() output AND click() either failed silently or is not the right verb.' 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that coordinate clicks always return OK even if nothing is hit, and that double_click cannot be combined with button='right'. It does not cover behavior like element visibility requirements or scroll-into-view, but the key quirks are addressed.
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 well-structured with a clear first sentence and logical flow. While slightly verbose, every sentence adds value. Front-loaded with the main purpose, then details on modes, caution, and parameter explanations.
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 essential contextual information: two click modes, pitfalls of coordinate clicks, and parameter constraints. Although an output schema exists (not shown), the description doesn't mention return values, but likely the schema covers that. Overall, it's 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It does so thoroughly: explains element_id vs x/y usage, button default and options, double_click behavior and incompatibility. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: clicking an element by ID or at screen coordinates. It provides two distinct modes and explains when to use each, distinguishing it from sibling tools like 'focus' or 'mouse_move'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use coordinates over element ID (e.g., when clicking by ID triggers an unintended action). It also warns about coordinate clicks always reporting success and recommends verification. However, it doesn't explicitly compare against other click-related siblings or mention when to use the tool itself via programmatic methods.
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?
Without annotations, the description fully discloses the read-only nature of the tool, stating it returns visible application names from the accessibility tree. There are no hidden side effects or behavioral surprises.
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 short sentences, both front-loaded with the core action. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (not shown but signaled), the description fully covers the tool's purpose, return value, and usage context. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none is 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 'List applications with accessible UI elements' and specifies that it returns application names from the accessibility tree. This distinctively sets it apart from sibling tools like 'windows' (which lists windows) and 'action' (which performs actions).
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 recommends using the app names as input for other tools (find, elements, screenshot), providing clear guidance on when to invoke this tool. It does not specify when not to use it, but for a simple list tool with no parameters, this is sufficient.
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 carries the full burden. It discloses 'Returns a fresh snapshot with current states, value, supported actions, and description', which gives good behavioral context. It does not mention side effects or auth requirements, but for a read-only inspection tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs plus a docstring-style parameter note. Every sentence adds value: purpose, usage guidance, and parameter clarification. It is front-loaded with the main action and efficiently 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?
With one parameter, an existing output schema (context signal), and clear indication of what the return includes (states, value, actions, description), the description is complete for the tool's complexity. An agent can confidently use it without additional clarification.
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 0%, but the description adds 'The element ID (from find/elements results)' for the single parameter, providing context about where the ID originates. This adds value beyond the schema. A 5 would require more specific format or constraints (e.g., UUID pattern).
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 begins with 'Get a single element by its ID with full detail', which uses a specific verb ('Get') and resource ('single element'), and clearly distinguishes from sibling tools like 'elements' (plural) and 'find' (returns list). The purpose is unambiguous and well-differentiated.
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 'Use this to inspect an element before calling the action() tool', providing clear when-to-use guidance. However, it does not explicitly state when not to use or mention alternatives, such as using 'find' for multiple elements, which would earn a 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, the description carries full burden. It discloses key behavioral traits: 'applies a native text selection over that range,' works on editable fields and document bodies, and on some backends works on read-only containers. It also explains the occurrence parameter. However, it doesn't mention if selection is visible or if it modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence summary, then two supporting sentences about behavior and use cases, followed by a clear parameter list. Every sentence adds value 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 complexity (3 parameters, no annotations, output schema exists), the description covers purpose, usage context, parameter semantics, and backend-specific behavior. It does not explain return values, but the output schema likely handles that. Minor gap: no mention of prerequisites (e.g., element must be focused or visible).
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?
Since schema_description_coverage is 0%, the description must compensate. It does so by explaining each parameter: element_id (the element containing text), text (exact substring to select), and occurrence (which occurrence to target), adding meaning beyond the schema's type and name.
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 starts with a clear verb+resource statement: 'Select a substring within an element's text content.' It specifies the exact action and distinguishes from sibling tools like read_text, set_value, and type_text.
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, e.g., 'Useful for formatting, copying, or replacing specific text.' It also explains backend-specific behavior (editable vs. read-only) but does not explicitly state when not to use or name 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?
No annotations provided, so the description fully bears the transparency burden. It discloses widget-dependent behavior, the atomic nature for combo boxes, and the replace parameter effect. Missing error conditions or side effects, but still 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 well-structured with a brief overview, bullet-pointed widget behaviors, and parameter details. Every sentence is informative and necessary; no fluff.
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?
Covers all parameters, widget-behavior breakdown, and usage hints. The presence of an output schema (not shown) offsets the lack of return-value explanation. Minor gap: no mention of error handling or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter thoroughly: element_id as the widget, value as text or option label, and replace with clear semantics (clear+replace vs insert). This adds rich meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the value of an editable element and lists specific widget behaviors (text fields, combo boxes, etc.), distinguishing it from siblings like type_text and click by emphasizing atomic value-setting via native API.
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 explicit usage guidance, e.g., preferring set_value over clicking for combo boxes to avoid popup failures. Though it does not list exclusions, the context is clear for when 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?
With no annotations, the description discloses polling behavior, auto-activation, and side effects on subsequent type_text/press_key. It lacks details on timeout failure behavior (e.g., exception), but covers major 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?
Description is concise, front-loaded with purpose, and every sentence adds value. Structured with clear paragraphs for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of annotations, the description covers usage, parameters, and behavior well. Minor gap: no mention of timeout failure behavior, but output schema may cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully explains all four parameters: title (substring match), app (filter), timeout (max seconds, default 10), gone (wait for disappear). Adds essential meaning beyond 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 waits for a window to appear or disappear, with a specific verb and resource. It distinguishes from sibling tools like wait_for (generic), wait_for_app (app-specific), and activate_window (no waiting).
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 after actions that open or close windows,' providing clear context. However, it does not mention when not to use it or list alternatives, though the context is sufficient for most 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?
No annotations provided, but description discloses matching behavior (by name, not body text), return type (element IDs), and source options including compatibility alias. No destructive side effects mentioned, appropriate for a read search 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?
Highly efficient: two sentences for purpose/constraints, then a usage tip, then a complete parameter list. Every sentence adds value; 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 no annotations and no output schema description, the description thoroughly covers input parameters and outcome (returns element IDs for interaction). Source and fields options are detailed, making it self-contained for an 8-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description's docstring explains all 8 parameters with clear semantics and examples (e.g., query: 'Send Message'). Fully compensates for schema lack.
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 it searches UI elements by name (buttons, links, labels, etc.) and explicitly excludes body text or prose. Distinguishes purpose from other tools by specifying return of element IDs for 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?
Provides when to use (search by name) and a tip for best results (use full visible text). Could explicitly contrast with alternatives (e.g., read_text for content), but context from sibling tools implies usage.
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 carries the full burden. It transparently discloses that with element_id, the cursor is moved to the element's center first before scrolling. It does not mention potential side effects like permanent cursor movement or scroll boundaries, but the behavior is adequately described for a simple scroll 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?
The description is concise and well-structured: a one-line summary followed by a terse paragraph explaining behavior with and without element_id, then a clean parameter listing. No superfluous text; every sentence adds value.
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 scrolling tool with an output schema (which handles return value documentation), the description covers all essential aspects: what it does, parameter meanings, and behavioral nuance. It is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only property names and types with no descriptions. The description adds critical meaning: it defines direction values as 'up', 'down', 'left', 'right', explains amount as 'Number of scroll ticks (default 3)', and clarifies element_id as optional and that it causes cursor movement. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Scroll by mouse wheel ticks,' which clearly states the tool's core action and resource. It distinguishes between scrolling with an element_id (for scrolling inside a container) and without, making its purpose 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 provides clear guidance on when to use the element_id parameter (for scrolling inside a specific list, panel, or container) versus without (scroll at current cursor position). However, it does not explicitly compare with sibling tools or state 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?
With no annotations, the description bears full burden. It discloses keyboard simulation, special character handling (\n, \t, \b), and raw mode. Missing details on clearing existing text, but overall 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?
Concise yet complete: two short paragraphs plus bullet-like arg definitions. Every sentence adds value, 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 and presence of output schema, the description covers prerequisites, parameter details, and special characters. No gaps for intended 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?
Schema coverage is 0%, and the description fully compensates by explaining both 'text' (the string to type) and 'raw' (literal backslash behavior) with clear semantics and examples.
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 'Type text into the currently focused element' with a specific verb and resource. It distinguishes from siblings like select_text and set_value by emphasizing simulation of keyboard 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?
Explicitly instructs to focus an element first using click() or focus(), providing clear prerequisite and usage context. Could mention alternatives but is sufficient.
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 provided, so description carries burden. It transparently describes the action and its typical use case, but lacks details on behavior in edge cases like minimized windows.
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?
Concise, front-loaded with the core purpose, and uses only necessary sentences. 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?
Simple tool with one parameter and output schema present. Description covers the main effect and usage context, but does not mention return value; however, output schema exists and obviates need.
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?
With 0% schema coverage, the description adds essential meaning: 'The window ID to activate (from windows())', specifying the source of the value, which fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bring a window to the foreground' and distinguishes from sibling tools by explaining that element-scoped actions automate this, so it's only needed for keyboard actions without clicks.
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 when to use (for type_text/press_key without clicking) and when not (rarely, since element-scoped actions already focus). Provides clear alternative 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 carries full burden. It honestly describes the action without contradiction. However, it could add minor behavioral details like 'the window is hidden and appears as an icon in the taskbar'. But for a simple action, it is 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?
Extremely concise: two sentences plus a bullet for the parameter. No unnecessary words. Action is front-loaded, and every sentence serves a 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 the tool's simplicity, the description covers prerequisites (use windows()), alternative actions (activate_window()), and parameter explanation. An output schema exists (not shown), so return values need not be described. Complete for its 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?
Only one parameter (window_id) with 0% schema description coverage. The description adds meaning by stating 'The window ID to minimize', which clarifies usage beyond the schema's mere title 'Window Id'.
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 action ('Minimize a window to the dock/taskbar') and identifies the specific resource (window). It effectively distinguishes from sibling tools like close_window, activate_window, and fullscreen_window.
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 tells when to use the tool (after finding window ID via windows()) and when not to use it (restoring a minimized window should use activate_window()). Provides clear context for usage.
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?
No annotations provided, so description carries full burden. Discloses polling behavior, timeout, multi-query mode (any/all), gone parameter, wait_for_new, and source options. Transparent about key behaviors.
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?
Front-loaded with a one-sentence summary, then structured bullet points for parameters. Every sentence adds value; no redundancy. Efficient for the complexity of 12 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no annotations, and an output schema, the description covers all necessary aspects: usage context, parameter behavior, and polling logic. Output schema handles return value, so no gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates fully. Provides detailed explanations for all 12 parameters, including default values, behavior for element as list, mode, and source aliases.
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 it waits for elements to appear or disappear, specifying verb ('wait'), resource ('elements'), and the two modes. Distinguishes from sibling tools like wait_for_app and wait_for_window by focusing on UI elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use 'after actions that trigger UI changes', providing clear context. However, does not mention exclusions or directly contrast with sibling tools like wait_for_app or wait_for_window.
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?
Describes default behavior (active window, accessibility tree walk, pruning anonymous wrappers, preserving semantic containers, indented text output) and all parameters' effects. No annotations provided, so description fully 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose statement followed by Args section. Each sentence adds value, no redundancy. Efficiently conveys all necessary information without being verbose.
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 an output schema, explanation of return values is not needed. Description covers all parameters, usage context, and alternatives, making it complete for a tool with 5 parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains all 5 parameters with details: case-insensitivity for app, usage of window_id, element_id for digging into containers, all_elements for including non-interactive, and max_depth for controlling depth. Adds significant meaning beyond bare 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 returns a tree-structured view of a window's UI, and distinguishes it from siblings like screenshot (structural complement) and read_text (for 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it's the primary orient tool in no-vision mode and a structural complement to screenshot in vision mode. Also advises using read_text for container text instead of snapshot, providing clear when-to-use and alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/Touchpoint-Labs/Touchpoint'

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