Windows Diagnostics MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific diagnostic areas like startup programs, BSOD events, registry health, and system uptime. However, some overlap exists between 'analyze_system_stability' and 'get_system_diagnostics', which could cause confusion as both provide system-wide assessments.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern throughout, such as 'analyze_startup_programs', 'get_bsod_events', and 'scan_security_risks'. The only minor deviation is 'find_orphaned_entries', which uses 'find' instead of a more common verb like 'scan' or 'get', but overall naming is highly predictable.
Tool Count5/5
With 11 tools, the count is well-scoped for a Windows diagnostics server, covering various aspects like registry analysis, system events, security, and stability. Each tool appears to serve a specific diagnostic function without redundancy, making the set appropriately sized for the domain.
Completeness4/5
The tool set provides comprehensive coverage for Windows diagnostics, including registry health, system events, security risks, and component scans. A minor gap is the lack of tools for real-time monitoring or automated repair actions, but core diagnostic workflows are well-covered without dead ends.
Average 3/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 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

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 mentions 'analyze' and 'provide recommendations', implying a read-only operation that might involve computation, but doesn't specify if it requires admin permissions, has side effects, or details the format of recommendations. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded in a single sentence, with no wasted words. However, it could be more structured by explicitly separating the analysis action from the output, but it efficiently conveys the core function without redundancy.
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 complexity implied by 'analyze' and 'recommendations', no annotations, and no output schema, the description is incomplete. It doesn't explain what 'stability' means in this context, what data sources are used, or the format of recommendations. For a tool that likely involves data aggregation and analysis, more context is needed to understand its full scope and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'daysBack' clearly documented. The description adds no parameter semantics beyond what the schema provides, such as explaining how the analysis period affects results or if there are constraints on the value. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('analyze system stability and provide recommendations'), which is clear but vague. It doesn't specify what 'system stability' entails or how it differs from sibling tools like 'get_system_diagnostics' or 'get_system_uptime'. The description avoids tautology but lacks specificity about the resource or scope.
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. With siblings like 'get_system_diagnostics' and 'get_system_uptime', the description doesn't explain if this tool aggregates data from them, provides a higher-level analysis, or serves a distinct purpose. There's no mention of prerequisites, exclusions, or recommended contexts.
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 what the tool does ('Get BSOD events') without mentioning permissions needed, rate limits, response format, or whether it's a read-only operation. This is inadequate for a tool that likely accesses system data, as it omits critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose ('Get Blue Screen of Death (BSOD) events'). It's appropriately sized for a simple tool, making it easy to parse without unnecessary elaboration.
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 complexity of retrieving system events, the lack of annotations and output schema means the description should compensate by explaining behavioral aspects like permissions or response format. It fails to do so, leaving gaps in understanding how the tool operates and what it returns, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'daysBack' parameter with its default and type. The description adds no additional parameter semantics beyond what the schema provides, such as format details or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Blue Screen of Death (BSOD) events', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'get_shutdown_events' or 'get_system_diagnostics', which might also retrieve system events, leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as sibling tools like 'get_shutdown_events' or 'analyze_system_stability'. It lacks context on prerequisites, exclusions, or specific scenarios where retrieving BSOD events is appropriate, leaving the agent without usage direction.
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 states the tool retrieves health assessment, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires admin permissions, how it calculates health, or if it has rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get an overall registry health assessment'. It is front-loaded with the core purpose and has zero wasted words, making it highly concise and well-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?
Given the complexity of assessing registry health, the description is incomplete. With no annotations, no output schema, and no details on what 'health' entails or how results are returned, the agent lacks sufficient context to understand the tool's scope and output. This is inadequate for a tool that likely involves system diagnostics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. The baseline for 0 parameters is 4, as the description doesn't need to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get an overall registry health assessment', which clearly indicates it retrieves health information about the registry. However, it doesn't specify what constitutes 'health' or differentiate it from sibling tools like 'scan_security_risks' or 'analyze_system_stability', making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'scan_security_risks' or 'search_registry'. The description implies usage for health assessment but lacks explicit context, exclusions, or prerequisites, leaving the agent to infer when this tool is appropriate.
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 states what events are retrieved but doesn't mention critical aspects like whether this is a read-only operation, what format the results come in, potential rate limits, authentication requirements, or how the data is structured. This leaves significant gaps for an 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 extremely concise at just 5 words, with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration, making it highly efficient for an agent to parse.
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 diagnostic tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the events come in, whether they're filtered or raw, what timezone is used, or how results are structured. Given the complexity of system events and lack of structured output information, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'daysBack' fully documented in the schema. The description adds no additional parameter information beyond what the schema already provides, which meets the baseline expectation when schema coverage is complete.
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 with a specific verb ('Get') and resource ('shutdown and reboot events'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_bsod_events' or 'get_system_uptime', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_bsod_events' and 'get_system_uptime' available, there's no indication of when this specific event type is appropriate or what distinguishes it from other diagnostic tools.
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 states the action is a search but doesn't cover critical aspects like whether this is read-only (likely, but not confirmed), potential system impact, permissions required, rate limits, or what the output looks like (e.g., format, pagination). For a registry tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for the tool's complexity, making it easy to parse quickly.
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 complexity of registry operations, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., safety, permissions), output format, and usage context relative to siblings. This leaves significant gaps for an AI agent to operate effectively in a multi-tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'keyword' which maps to the 'searchTerm' parameter, adding some context. However, with 100% schema description coverage, the schema already documents both parameters thoroughly (e.g., 'searchTerm' as 'Keyword to search for', 'maxResults' with default). The description doesn't provide additional syntax, format, or usage details beyond what's in the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target resource ('Windows registry') with the method ('by keyword'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'find_orphaned_entries' or 'scan_security_risks' that might also involve registry operations, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., troubleshooting vs. security scanning), or exclusions, leaving the agent to infer usage from the name alone. This is a significant gap given the multiple sibling tools that could overlap.
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 states the tool scans for 'issues' but doesn't specify what constitutes an issue, whether the scan is read-only or modifies data, how long it takes, or what the output looks like. For a scanning tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose. It's appropriately sized for a zero-parameter tool, with no wasted words. However, it could be slightly more front-loaded by specifying the exact types of issues scanned for, but this is a minor improvement.
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 complexity of scanning system components and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'issues' means, what the scan entails, or what results to expect. For a tool that likely returns diagnostic information, more context is needed to understand its behavior and 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 schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline of 4 is appropriate as the description doesn't contradict or compensate for any parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scan') and target resources ('system components like services, drivers, and uninstall entries'), specifying what the tool does. It distinguishes itself from siblings by focusing on scanning for 'issues' rather than analyzing, finding, or getting specific data types. However, it doesn't explicitly differentiate from 'scan_security_risks' or 'get_system_diagnostics', which could involve similar scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions scanning for 'issues' but doesn't specify what types of issues, when this scan is appropriate, or how it differs from sibling tools like 'scan_security_risks' or 'get_system_diagnostics'. There's no mention of prerequisites, exclusions, or recommended contexts for usage.
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 mentions 'analyze' and 'suspicious entries,' implying a read-only diagnostic operation, but doesn't specify if it requires admin privileges, what 'suspicious' entails (e.g., malware, bloatware), or the output format (e.g., list, report). For a tool with zero annotation coverage, this lacks critical details about execution and results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Analyze startup programs for suspicious entries.' It's front-loaded with the core action and target, with zero wasted words. Every part of the sentence directly contributes to understanding the tool's function, making it highly concise and well-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?
Given the complexity of analyzing 'suspicious entries' (which could involve security, performance, or system health), the description is incomplete. No annotations exist to clarify behavior, and there's no output schema to explain return values. The description doesn't address what 'analyze' entails (e.g., scanning, reporting, flagging) or how results are presented, leaving significant gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for zero parameters is 4, as the description appropriately focuses on the tool's purpose without redundant parameter explanations. No additional semantic value is required or provided.
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 purpose: 'Analyze startup programs for suspicious entries.' It specifies the verb ('analyze'), resource ('startup programs'), and target ('suspicious entries'), which distinguishes it from siblings like 'scan_security_risks' or 'get_system_diagnostics.' However, it doesn't explicitly differentiate from 'scan_system_components' or 'find_orphaned_entries,' which could overlap in scope, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'scan_security_risks' and 'scan_system_components,' it's unclear if this tool is for security-focused analysis, performance checks, or general diagnostics. There's no mention of prerequisites, context (e.g., post-infection scans), or exclusions, leaving usage ambiguous.
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 states what the tool does but doesn't describe how it behaves: no information on permissions required, whether it's read-only or destructive, performance characteristics, error handling, or output format. For a tool with zero annotation coverage, 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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a no-parameter tool and front-loads the essential information without unnecessary elaboration.
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 and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of entries, a report, or just a count), how results are formatted, or any behavioral traits like safety or performance. For a tool with no structured metadata, the description should provide more context about operation and 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 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't discuss parameters. It focuses on the tool's purpose instead.
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 purpose: 'Find orphaned registry entries pointing to non-existent files'. It specifies the action ('Find'), the resource ('orphaned registry entries'), and the condition ('pointing to non-existent files'). However, it doesn't explicitly differentiate from sibling tools like 'search_registry' or 'get_registry_health', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or how it differs from sibling registry tools like 'search_registry' or 'get_registry_health'. The user must infer usage from the purpose alone.
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 full burden for behavioral disclosure. It mentions what information is included ('crashes, reboots, and system health') but doesn't describe the return format, whether it requires admin privileges, if it's a read-only operation, or any performance/rate considerations. For a diagnostic tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized and front-loaded with the essential 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?
For a diagnostic tool with 2 parameters (fully documented in schema) but no annotations and no output schema, the description provides basic purpose but lacks behavioral context and usage guidance. It's minimally adequate but has clear gaps in explaining what the tool actually returns and when to use it versus siblings.
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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('comprehensive Windows system diagnostics') with specific scope ('including crashes, reboots, and system health'). It distinguishes from some siblings like 'get_bsod_events' or 'get_system_uptime' by being more comprehensive, though it doesn't explicitly differentiate from all siblings like 'analyze_system_stability'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_bsod_events', 'get_shutdown_events', and 'analyze_system_stability', there's no indication of when this broader diagnostic tool is preferable to more specific ones or what context warrants its use.
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 states the action ('scan') but doesn't describe what the scan entails, such as whether it's read-only, destructive, requires permissions, or has side effects like performance impacts. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a tool with no parameters.
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 complexity of a security scanning tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'potential security risks' means, the scan's scope, output format, or any behavioral traits, making it inadequate for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scan') and target ('registry for potential security risks'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_registry' or 'scan_system_components', which could involve similar scanning operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as how it differs from 'search_registry' or 'scan_system_components'. It lacks explicit context, prerequisites, or exclusions, leaving usage ambiguous.
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. While 'Get' implies a read-only operation, it doesn't specify details like whether this requires admin permissions, how the information is formatted, or if there are any rate limits. The description is too minimal to fully inform the agent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks details on behavioral context or usage guidelines, which could be helpful for an agent to operate effectively in a server with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required or provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current system uptime and boot information'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_system_diagnostics' or 'analyze_system_stability', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_system_diagnostics' and 'analyze_system_stability' available, there's no indication of whether this tool is for basic uptime retrieval versus more comprehensive analysis, leaving usage context unclear.
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

windows-diagnostic-mcp-server MCP server

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![windows-diagnostic-mcp-server MCP server](https://glama.ai/mcp/servers/jackalterman/windows-diagnostic-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/jackalterman/windows-diagnostic-mcp-server)

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/jackalterman/windows-diagnostic-mcp-server'

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