Clara Windows UI MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action: listing windows, getting foreground, focusing, capturing, mouse movement/click, and keyboard input. No overlap in purpose, unambiguous.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (list_windows, get_foreground_window, capture_screen, etc.) with snake_case, perfectly predictable.
Tool Count5/5
8 tools is well-scoped for a Windows UI automation server, covering window management, screen capture, and input simulation without bloat or thinning.
Completeness4/5
The set covers core UI automation workflows (window handling, mouse/keyboard input, screenshot). Minor gaps like reading window properties or mouse scroll are not critical but could be added.
Average 3.2/5 across 8 of 8 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/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 only says 'Click' without explaining that a click involves pressing and releasing a button, potential side effects like focus changes, or that doubleClick toggles a double-click. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It omits essential details that an agent needs to call the tool correctly. While brevity is good, this description is so short that it fails to earn its place by conveying necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description is severely incomplete. An agent needs to know that coordinates are screen-relative, that doubleClick toggles a double-click, and the meaning of each button option. With no annotations to supplement, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meanings. It does not describe x and y coordinates (e.g., screen-relative, units), the button enum options, or the doubleClick boolean. The only hint is 'selected mouse button', which vaguely refers to the button parameter but adds no real value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Click') and resource ('screen coordinate'), and clarifies it uses a mouse button. This clearly distinguishes it from siblings like move_mouse (no click) and press_key (keyboard action). The purpose is unambiguous even without explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention typical use cases (e.g., clicking UI elements) or that move_mouse should be used for positioning without clicking. There are no exclusions or conditions 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 must carry the full behavioral burden. It states only the primary action but does not disclose any side effects, such as whether the cursor movement triggers hover events, whether the coordinates are relative to a primary monitor or virtual desktop, or any error handling for out-of-bounds input. The description adds little beyond the tool name.
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 unnecessary wording. It is front-loaded with the action and resource. For a simple tool, this is appropriately 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?
The tool is a basic input action with two parameters, so a short description might be acceptable. However, missing context about coordinate interpretation (e.g., multi-monitor setups) and lack of any behavioral notes (e.g., does it move instantly or animate?) means an agent might not know edge cases. It 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal parameter definitions (integer types with huge ranges) and no descriptions. The description mentions 'absolute screen coordinate' but does not clarify the coordinate system, units, or boundary behavior. Since schema coverage is 0%, the description fails to compensate, leaving the agent without meaningful param semantic 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 states the specific action ('Move the mouse cursor') and the resource ('absolute screen coordinate'), which clearly distinguishes this from sibling tools like click_mouse or type_text. It is not a tautology because it adds the 'absolute' qualifier, making the tool's scope clear even without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 instance, it does not mention that this avoids clicking or scrolling, or that it can be used for positioning before a click. The description leaves the usage context entirely implicit.
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 the full burden of behavioral disclosure. It only says 'Capture the desktop or a specific window to a PNG file' but does not reveal that it writes a file (a side effect), how the selector behaves when omitted, whether it blocks, or any permission requirements. This is insufficient for a tool that performs a write 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, front-loaded sentence with zero fluff. It states the action, scope, and output directly. While it is terse, the conciseness is appropriate given the tool's apparent simplicity.
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 no annotations, no output schema, and 0% schema coverage, the description is severely incomplete. It does not explain the effect of omitting parameters, the return value (or lack thereof), file overwrite behavior, or any error conditions. An agent would have to guess about the required output path and selector semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. The phrase 'the desktop or a specific window' hints that the 'selector' parameter is used to pick a window, but it does not explain how 'handle' or 'titleIncludes' work, nor does it mention 'outputPath' or its default. The description adds only vague conceptual meaning, not operational detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture') and the resource ('the desktop or a specific window') with an explicit output type ('to a PNG file'). It is specific enough to distinguish from sibling tools like list_windows, focus_window, and input tools.
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. There is no mention of when to choose this over list_windows or get_foreground_window, nor any prerequisites or exclusions. The description is purely declarative.
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 must carry the full burden, but it only states the action without covering side effects (e.g., what if the window is minimized), error behavior, or whether it activates vs merely raises. Minimal behavioral disclosure beyond the verb itself.
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, dense sentence that front-loads the core action and identification methods with no wasted words. Highly concise and appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description omits crucial contextual details: behavior when neither parameter is provided, behavior when both are provided, and what happens if no window matches. No output schema or annotations to fill gaps, leaving the agent uncertain about edge cases.
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 adds meaning by mapping 'handle' to HWND and 'titleIncludes' to partial title match, but provides no details on format, case sensitivity, or precedence when both are given. Partial compensation but not thorough.
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 'bring to foreground' and the resource 'target window', and specifies two identification methods (HWND or partial title match). This distinguishes it from siblings like list_windows (listing) and get_foreground_window (querying).
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 like list_windows or get_foreground_window. It does not explain when to prefer a handle vs titleIncludes, or any preconditions. The intended usage is implied 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.
Behavior2/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 does mention that special characters are escaped, which is a useful behavioral detail, but it fails to disclose that the action sends keystrokes to the foreground window, may require a focused window, or that it mutates system state. This is a significant gap for a UI automation 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 a single concise sentence with no fluff. It is front-loaded with the primary action ('Type text') and the method, followed by a key behavior. Every word 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 simplicity, the description is still incomplete. It does not mention the prerequisite of a focused window, potential errors (e.g., no window focused), or any output/return behavior. The agent is left without critical context to invoke it reliably, especially since there is no output schema or annotations to fill the 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 0%, so the description must compensate. The phrase 'special characters escaped' adds meaning to the 'text' parameter, indicating that special characters are handled automatically. However, it does not explain format, length limits, or provide examples. It adds some value but not enough to fully clarify the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Type') and resource ('text') with the method ('through SendKeys') and a key behavior ('special characters escaped'). It clearly distinguishes from siblings like press_key (single key) and move_mouse/click_mouse, which the agent can infer as alternatives without ambiguity.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention that it types into the focused window or requires a prior focus_window call, nor does it contrast with press_key for single keys. Usage context is implied by the tool name and siblings but not stated, leaving the agent to infer.
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 of behavioral disclosure. It only states 'get' without specifying the return format (e.g., window ID, title), side effects (none implied but not explicit), or platform-specific behavior. For a tool with zero annotations and no output schema, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero fluff. For a tool with no parameters, this is appropriately sized. It immediately conveys the core purpose without unnecessary complexity.
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 lack of annotations, output schema, and parameters, the description must provide enough context for an agent to call and interpret the result. It fails to explain what the 'foreground window' represents, what data is returned (e.g., handle, title, bounds), or how to use the output. The description is adequate only for knowing the tool's existence, not for reliable 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?
The tool has zero parameters, so the baseline is 4 per the rubric. The description correctly omits parameter details since there are none, and the schema already covers 100% of the (empty) parameter set. No additional semantic information 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 the action ('get') and the specific resource ('current foreground window'). This distinguishes it from sibling tools like list_windows (which likely enumerates all windows) and focus_window (which sets focus). An agent can immediately understand the tool's role.
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. The description does not mention that this is for the active window as opposed to listing all windows, nor does it indicate any prerequisites or complementary usage with focus_window or capture_screen. An 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.
Behavior2/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 only states the action (sending a key sequence) without mentioning that keys are dispatched to the active window, that timing or delays might apply, or any side effects. This is a significant gap for a tool that operates on UI 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 a single, front-loaded sentence that immediately conveys the core action and includes examples. No wasted words; it is as concise as possible while remaining informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that interacts with the active window and has no annotations, the description is insufficient. It omits critical context such as window focus requirements, behavior when multiple keys are passed, error conditions, and what (if anything) is returned. Given the tool's simplicity, a more thorough description should exist.
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 no description for the 'key' parameter, and schema description coverage is 0%. The description gives two examples but does not explain the full SendKeys syntax, such as how to combine modifiers, escape characters, or represent special sequences beyond the two examples. It adds some value but is incomplete for a robust 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 a specific verb ('Send') and resource ('key sequence through SendKeys syntax'), with concrete examples like {ENTER} or ^a. It effectively distinguishes the tool from the sibling type_text, which handles plain text input, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for special keys and shortcuts via the SendKeys syntax and examples, but it does not explicitly mention when to use this versus alternatives like type_text, nor does it state prerequisites (e.g., having a focused window). The guidance is implicit rather than 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?
No annotations exist, so the description carries the full burden. It does add meaningful scoping — 'visible top-level' tells the agent that hidden/minimized windows and child windows are excluded, and 'foreground state' discloses that focus status is reported. However, it leaves common behavioral questions open for a list operation: ordering, result-size limits, and whether handles are live/current. Decent but not comprehensive 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?
A single front-loaded sentence with zero waste: action verb first, resource scope next, then the full output field list. Every element earns its place and no wording is redundant.
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 no output schema and no annotations, the description is the only channel conveying the return shape, and it does so thoroughly by enumerating all returned data fields. The operation is simple and zero-arg, so nothing essential is missing; only minor details (ordering, blocking behavior) go unmentioned.
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 takes zero parameters, so the schema has nothing to explain and there is nothing the description needs to add. Per the rubric baseline for 0-param tools, a 4 is appropriate — the description correctly focuses on behavior rather than 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?
States a specific verb ('List') and a precisely scoped resource ('visible top-level windows'), then enumerates the exact output fields (HWND, title, process info, bounds, foreground state). This clearly differentiates it from siblings like get_foreground_window (single focused window) and focus_window (changes focus), so an agent can tell operations apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated. An agent would infer this tool answers 'what windows are open?' queries, and the foreground-state field hints it complements get_foreground_window, but the description never explicitly says when to prefer it over a sibling (e.g., when you need a specific window's handle vs. enumerating all). No exclusions or alternatives are named.
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:

[![clara-windows-ui-mcp MCP server](https://glama.ai/mcp/servers/BestCodeTools/clara-windows-ui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BestCodeTools/clara-windows-ui-mcp)

Score Badge

Copy to your README.md:

[![clara-windows-ui-mcp MCP server](https://glama.ai/mcp/servers/BestCodeTools/clara-windows-ui-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BestCodeTools/clara-windows-ui-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/BestCodeTools/clara-windows-ui-mcp'

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