A-Eyes

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Several tools (see, capture, query, watch) all capture screenshots, which could cause confusion. However, each has a distinct purpose: UI tree inspection, raw screenshot, Q&A, and change detection, and the descriptions help differentiate them. The overlap between see and capture is the most concerning, as see also returns a screenshot.
Naming Consistency2/5
Tool names follow no consistent pattern: single-word verbs (see, capture, query, watch) are mixed with compound noun/verb names (list_windows, check_status) and plain nouns (processes, clipboard, event_log). The naming style is inconsistent and lacks the predictable verb_noun convention seen in high-scoring servers.
Tool Count4/5
With 11 tools, the set is well within the typical 3-15 range and covers a broad but focused domain of Windows observation, diagnostics, and configuration. Each tool adds a distinct capability, and the count does not feel bloated for the server's purpose.
Completeness4/5
The server provides solid coverage for visual UI inspection, screenshot capture, system diagnostics, and clipboard access. Missing interaction tools (click, type, launch) are a notable gap, but given the server's 'A-Eyes' (vision-focused) intent, the absence of manipulation tools may be a deliberate design choice. Custom PowerShell execution partially compensates for missing operations.
Average 3.9/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether the screenshot is transmitted to an external service, what the response format is, or any privacy implications. The tool name and description imply a non-destructive query, but the lack of explicit behavioral context 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 two sentences long, with the first sentence stating the purpose and the second providing a specific usage tip. Every sentence earns its place, with no redundant or irrelevant information. It is front-loaded with the core purpose and efficiently communicates the essential usage nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested object, no output schema), the description is too minimal. It does not explain expected return values, how to choose mode, or when to prefer this over sibling tools. The schema covers parameter semantics, but the description lacks high-level context for an agent to decide on usage scenarios and anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are individually documented. The description adds a cross-parameter rule ('Omit both...') which is already implied by each parameter's 'Omit to capture the foreground window' phrasing. Thus, the description adds little beyond the schema, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: capture a screenshot of a window and ask a question about its content. It uses a specific verb ('capture' and 'ask') and identifies the resource (window content). However, it does not explicitly differentiate from sibling tools like 'capture' or 'see', which may also involve screenshots, so it misses the highest mark.
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 a clear usage instruction: omit both window_title and process_name to capture the focused foreground window. This gives context for a common use case. However, it does not explain when to use this tool over alternatives like 'capture' or 'see', nor does it mention exclusions or prerequisites (e.g., screen mode allowlist), so it falls short of explicit when/when-not guidance.
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 'Run a custom PowerShell tool' without mentioning potential side effects, permissions, or output behavior. For a tool that executes arbitrary scripts, 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?
Two sentences: the first states the purpose, the second provides a necessary pointer to list_custom_tools. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description is minimal. It references the config file and list_custom_tools, but omits important behavioral details about script execution and system effects. For an arbitrary script runner with potentially broad impact, this is insufficient.
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 covers both parameters (tool_name and params) with clear descriptions, achieving 100% coverage. The description adds that the tool must be registered in a-eyes.config.json, which provides context for tool_name, but does not elaborate further 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 action ('Run a custom PowerShell tool') and the resource ('registered in a-eyes.config.json'). It distinguishes from siblings by referencing list_custom_tools for discovery, making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to use list_custom_tools to see available tools, which is a useful prerequisite for choosing the correct tool_name. However, it does not explicitly contrast with alternative tools or state when not to use this tool, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'capture', which is essentially the tool's name. It does not disclose whether the operation is read-only, what happens if the window is not found, or the return format/side effects. The schema descriptions provide some behavioral details, but the description itself adds no safety or failure context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by an important usage tip. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters and no output schema, so the description should explain the return value and any nuances like screen mode. The schema covers parameter semantics well, but the description omits the output format (base64 image) and screen capture behavior. It is adequate for basic use but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 10 parameters, so the schema fully documents each parameter. The description only repeats window_title and process_name without adding new meaning, thus meeting the baseline but not exceeding it.
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 captures a screenshot of a window by title or app name, using a specific verb and resource. It does not explicitly differentiate from sibling tools like 'see' or 'query', but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains how to capture a specific window (by title or process name) and that omitting both captures the foreground window. However, it does not mention when to use this tool versus alternatives or mention screen capture mode.
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 only states 'list all visible windows' but doesn't explain what 'visible' means (e.g., excludes minimized windows?), what data is returned (titles, handles, positions), or whether it includes all desktop windows. This lack of detail could lead to incorrect assumptions.
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 scope. There is no verbosity or filler; every word contributes meaning ('List all visible windows on the Windows desktop').
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 (no params), but the description is minimal and lacks critical details like return format or what fields are included for each window. Since there is no output schema, the description should compensate by indicating whether it returns titles, process IDs, coordinates, etc. It does not, leaving the agent with an incomplete picture of the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object with 100% schema coverage. Since there are no parameters to document, the description doesn't need to elaborate. The baseline score of 4 for zero-parameter tools is appropriate; no semantic gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'List all visible windows on the Windows desktop'. It is distinct from sibling tools like 'processes' (which lists processes) and 'see' (likely a screenshot tool), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does, without mentioning conditions, prerequisites, or exclusions (e.g., when to use 'see' or 'query' instead). This leaves the agent with limited decision support.
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 that the tool checks three specific components, which is useful, but it does not explicitly state whether it is read-only, what it returns, or any side effects (e.g., initiating WSL). The verb 'check' implies non-mutating behavior but lacks explicit detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a colon-separated list. It is concise and front-loaded, 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?
For a simple zero-parameter tool with no output schema, the description covers the core scope. However, it does not describe the return format or exit status, which would help an agent interpret results. This minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add parameter semantics. The baseline of 4 applies given the zero-parameter case.
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 'Check A-Eyes health', a specific verb+resource pair, and then lists three distinct areas (config, WSL interop, script availability). This clearly differentiates it from sibling tools like capture or list_windows that handle other functions.
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 guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it state any prerequisites or exclusions. An agent would have to infer its role from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It adds the useful detail that reading an image returns base64 PNG, but it does not describe error handling, side effects of writing (e.g., overwriting), or behavior when the clipboard contains unsupported content. This is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the primary read/write functionality and adding the image format detail in the second sentence. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema, no annotations), the description is nearly complete. It explains both operations and the image return format, but leaves a minor gap by not indicating what happens on write or whether text returns are plain strings. Overall, it's adequate for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'action' and 'text' parameters already having descriptive explanations. The tool description does not add parameter-specific meaning beyond what the schema provides, so it stays at the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs: 'Read' and 'write', and identifies the resource as the current Windows clipboard. It further distinguishes behavior for text vs. image content, including the base64 PNG format for images, making it distinct from any sibling 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?
While no explicit alternatives or exclusions are mentioned, the description provides clear context for when to use the tool: whenever clipboard access is needed for reading or writing text/images. The sibling tools are unrelated to clipboard operations, so the usage context is sufficiently 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?
With no annotations provided, the description carries the full burden. It says 'Read' which implies a non-destructive operation, and mentions the config requirement, but does not disclose what happens if the config is missing, any potential side effects, or ordering/pagination behavior. This is adequate but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with information front-loaded. The purpose is stated first, followed by use cases and a configuration note. 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 no output schema, the description could clarify what the returned data looks like, but it covers purpose, use cases, and a prerequisite. For a simple read tool with well-documented parameters, this is sufficient, though slightly more detail about output format would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning, such as implying 'recent' for count and explicitly naming the Application and System sources, but it doesn't significantly go beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads recent entries from the Windows Event Log, specifying the Application and System logs. It separates this from sibling tools by focusing on a specific log source and diagnostic use case, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions when to use the tool (diagnosing crashes, service failures, driver issues, .NET errors) and states a prerequisite (allow_event_log: true). It doesn't explicitly name alternatives or exclusions, but the use cases are clear enough for an agent to distinguish it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two behavioral modes (preview vs. write) and their triggers, which is helpful. However, since no annotations are provided, it carries the full burden but doesn't mention potential side effects like overwriting an existing config or whether preview is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose, and each sentence provides essential information without redundancy or excessive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers the main usage modes and what to expect from each. It doesn't mention the exact output format or edge cases, but given the low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the allowlist parameter fully (100% coverage), and the description adds meaning by explicitly connecting the parameter to the write action ('with an allowlist to write the config'). This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs: 'preview open windows' and 'create an allowlist config.' It distinguishes itself from sibling tools like capture or list_windows by focusing on configuration setup rather than capture or listing 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?
It explains exactly when to call without parameters ('to preview') and when to call with an allowlist ('to write the config'). While it doesn't explicitly mention alternatives or exclusions, it 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: polling until change, returning the changed screenshot, requiring explicit window/process identification, and the screen mode sentinel. It does not describe side effects (though a watch operation is inherently non-mutating) or error behaviors, but the explicit constraints and workflow are well covered.
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—only two sentences—yet packs in the primary action, the return value, and critical constraints. It is front-loaded with the verb and resource, making it easy to scan. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (five parameters, no output schema, no annotations), the description covers the essential context: what it does, the requirement for window_title/process_name, and the screen mode sentinel. It does not explain timeout behavior or return format in detail, but these are partially covered by the schema's parameter descriptions. A complete description could mention the timeout fallback, but this is still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for all parameters, including the requirement for either window_title or process_name and the mode options. The description reinforces these constraints (e.g., frontmost not supported, '__screen__' sentinel) but adds minimal new meaning beyond what the schema already offers. The high schema coverage warrants a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to poll a window until its visual content changes, then return the changed screenshot. It uses a specific verb ('poll') and resource (window content), which distinguishes it from siblings like 'capture' or 'see' that likely take single snapshots.
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 the tool: when you need to watch for visual changes in a window. It also includes important exclusions (frontmost capture not supported) and a specific requirement (window_title or process_name). However, it does not explicitly compare to alternatives or state when not to use it beyond the frontmost limitation.
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 the output fields (CPU, memory, PID) and a key behavioral nuance: omitting the name returns top processes by CPU. It does not mention permissions or edge cases, but the read-only nature is implied by 'List', and the description provides meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and resource. Every sentence contributes either purpose, use case, or a usage tip. No filler or 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?
For a tool with three optional, well-documented parameters and no output schema, the description provides enough context: what it lists, when to use it, and a behavioral default. It lacks explicit output format, but the schema fills in parameter details. Slightly more could be said about return shape, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a parameter-specific nugget (omitting 'name' yields top processes by CPU) that enriches the schema's default value documentation. This extra guidance justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'running Windows processes' and explicitly names the returned attributes (CPU usage, memory, PID). It clearly distinguishes this from sibling tools like 'capture' or 'list_windows' by focusing on process details. The intended use for diagnosing performance issues is also explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('diagnosing performance issues or checking if a specific app/service is running') and offers a usage tip ('Omit name to get the top processes by CPU'). It does not explicitly exclude alternatives or name sibling tools, but the guidance is sufficient for an agent to decide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It reveals that the tool captures a window, returns a UI tree, and describes internal behavior ('Both modes walk the element tree internally to harvest nested text'). It implies a read-only snapshot, though it doesn't explicitly state side effects or permissions. This is adequate for a non-destructive capture 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?
Three well-structured sentences: purpose, usage context, and parameter guidance. It is front-loaded, every sentence earns its place, and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description covers the essential aspects: what it captures, what it returns, and how to target a window. It is reasonably complete given the tool's simplicity, though it could nod to exceptional behaviors (e.g., accessibility restrictions or failure modes) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, providing a baseline of 3. The description adds valuable guidance beyond the schema: 'Omit both window_title and process_name to inspect the currently focused foreground window,' which clarifies optionality and default behavior.
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 a window and return its UI element tree... plus a screenshot' using a specific verb and resource. It distinguishes itself from siblings by emphasizing the element tree and the 'without asking a specific question' use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to understand what is visible in an application without asking a specific question,' providing a clear when-to-use context. It does not explicitly mention alternative tools like 'capture' or 'query', but the guidance is still actionable, including the tip to omit parameters for the foreground window.
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:

[![A-Eyes MCP server](https://glama.ai/mcp/servers/florian-priegnitz/A-Eyes/badges/card.svg)](https://glama.ai/mcp/servers/florian-priegnitz/A-Eyes)

Score Badge

Copy to your README.md:

[![A-Eyes MCP server](https://glama.ai/mcp/servers/florian-priegnitz/A-Eyes/badges/score.svg)](https://glama.ai/mcp/servers/florian-priegnitz/A-Eyes)

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/florian-priegnitz/A-Eyes'

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