This Windows Diagnostics MCP Server enables AI agents to perform comprehensive Windows system and registry diagnostics through the Model Context Protocol (MCP).
System Diagnostics:
Get comprehensive reports on Windows events, crashes, reboots, and system health with configurable time periods
Identify and retrieve Blue Screen of Death (BSOD) events
Obtain current system uptime and boot information
Analyze system stability and receive actionable recommendations
Registry Diagnostics:
Search the Windows registry by keyword with configurable result limits
Analyze startup programs for suspicious entries
Scan critical system components like services, drivers, and uninstall entries for issues
Find orphaned registry entries pointing to non-existent files
Receive overall registry health assessments
Scan for potential security risks
Runs as a Node.js application to provide Windows diagnostic tools and system analysis capabilities through a standardized interface.
Built using TypeScript for type safety and better code organization when implementing Windows diagnostic functionality.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Windows Diagnostics MCP Server check for any crashes or stability issues in the last 3 days"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides comprehensive Windows system diagnostic capabilities to AI agents. This server allows agents to access Windows event logs, crash information, system uptime, stability analysis, and Windows registry diagnostics.
System Diagnostics: Comprehensive analysis of Windows events, crashes, and system health
BSOD Detection: Identifies Blue Screen of Death events and critical system errors
Shutdown Analysis: Tracks expected and unexpected system shutdowns
Application Crash Monitoring: Monitors application crashes and failures
System Stability Scoring: Provides stability analysis with actionable recommendations
Uptime Tracking: Reports system uptime and boot information
Registry Search: Search the Windows registry by keyword
Startup Program Analysis: Analyze startup programs for suspicious entries
System Component Scanning: Scan services, drivers, and uninstall entries for issues
Orphaned Entry Detection: Find orphaned registry entries pointing to non-existent files
Registry Health Assessment: Overall registry health evaluation
Security Risk Scanning: Scan for potential security risks in the registry
Related MCP server: Windows MCP Server
Windows 10/11 or Windows Server
Node.js 18+
PowerShell 5.1+ (built into Windows)
Administrator privileges (recommended for full functionality)
PowerShell execution policy configured to allow script execution
Clone or download the files:
mkdir windows-diagnostics-mcp
cd windows-diagnostics-mcpSave the TypeScript server code as src/index.ts
Create package.json with the provided configuration
Create tsconfig.json with the provided TypeScript configuration
Install dependencies:
npm installConfigure PowerShell execution policy (if not already set):
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserOr for system-wide access (requires Administrator):
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachineBuild the server:
npm run buildAdd this to your Claude Desktop configuration file (%APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"windows-diagnostics": {
"command": "node",
"args": ["C:\\path\\to\\your\\windows-diagnostics-mcp\\build\\index.js"],
"env": {
"NODE_ENV": "production"
}
}
}
}Important: For full functionality, run Claude Desktop as Administrator to ensure proper access to event logs and registry.
The server can be started with:
node build/index.jsThe MCP server provides the following tools that agents can use:
get_system_diagnosticsComprehensive system diagnostic report including all event types.
Parameters:
daysBack (number, default: 7): Days to look back for events
detailed (boolean, default: false): Include detailed event information
get_shutdown_eventsGet shutdown and reboot events only.
Parameters:
daysBack (number, default: 7): Days to look back for events
get_bsod_eventsGet Blue Screen of Death (BSOD) events.
Parameters:
daysBack (number, default: 7): Days to look back for events
get_system_uptimeGet current system uptime and boot information.
Parameters: None
analyze_system_stabilityAnalyze system stability and provide recommendations.
Parameters:
daysBack (number, default: 30): Days to analyze for stability assessment
search_registrySearch the Windows registry by keyword.
Parameters:
searchTerm (string, required): Keyword to search for in the registry
maxResults (number, default: 50): Maximum number of results to return
analyze_startup_programsAnalyze startup programs for suspicious entries.
Parameters: None
scan_system_componentsScan system components like services, drivers, and uninstall entries for issues.
Parameters: None
find_orphaned_entriesFind orphaned registry entries pointing to non-existent files.
Parameters: None
get_registry_healthGet an overall registry health assessment.
Parameters: None
scan_security_risksScan the registry for potential security risks.
Parameters: None
Once configured with an MCP-compatible client, agents can use commands like:
"Check my system for any crashes in the last week"
"Analyze my Windows system stability"
"Show me recent BSOD events"
"What's my current system uptime?"
"Give me a comprehensive diagnostic report"
"Search the registry for entries related to 'Adobe'"
"Analyze my startup programs for suspicious entries"
"Check for orphaned registry entries"
"Scan my registry for security risks"
"Give me an overall registry health assessment"
"Scan system components for issues"
Administrator Rights: Run with administrator privileges for complete event log and registry access
PowerShell Execution: The server executes PowerShell scripts to gather system information
Registry Access: Registry operations require appropriate permissions and can potentially impact system stability
Local Only: This server only accesses local system information, no network requests
Event Log Access: Requires appropriate permissions to read Windows Event Logs
Execution Policy: PowerShell execution policy must allow script execution
PowerShell Execution Policy Error:
cannot be loaded because running scripts is disabled on this systemSolution: Configure PowerShell execution policy:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserAccess Denied Errors:
Run the MCP client (e.g., Claude Desktop) as Administrator
Some event logs and registry keys require elevated privileges
Check user account permissions
Registry Access Errors:
Ensure proper permissions for registry access
Some registry keys require SYSTEM-level access
Run as Administrator for full registry access
JSON Parse Errors:
Check that PowerShell is outputting valid JSON
Verify no additional output is being written to stdout
Check for PowerShell version compatibility
No Events Found:
Normal if system has been stable
Try increasing the daysBack parameter
Check if Event Log service is running
Script Execution Blocked:
Verify PowerShell execution policy settings
Check for antivirus software blocking script execution
Ensure PowerShell modules are not corrupted
Enable debug logging by setting environment variable:
set DEBUG=mcp:*
node build/index.jsThe server requires PowerShell scripts to execute. Common execution policies:
Restricted: No scripts allowed (default on some systems)
RemoteSigned: Local scripts allowed, downloaded scripts must be signed
Unrestricted: All scripts allowed (not recommended)
Check current policy:
Get-ExecutionPolicyRecommended setting for this server:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserThe server monitors these Windows Event Log entries:
1074: System shutdown initiated by user/application
1076: System shutdown reason recorded
6005: Event Log service started (boot)
6006: Event Log service stopped (shutdown)
6008: Unexpected shutdown detected
6009: System started
6013: System uptime reported
41: Kernel-Power critical error (unexpected shutdown)
1001: Windows Error Reporting BSOD
1003: System crash dump created
1000: Application error/crash
1001: Application hang
1002: Application recovery
219: Driver loading issues
7026: Service start failures
7000: Service start failures
7009: Service timeouts
7031: Service crashes
The registry diagnostic tools examine:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run
Startup folder entries
Installed services
Device drivers
Uninstall entries
System file associations
Security policies
User account settings
Network configurations
Browser settings
The server provides structured information including:
Event timestamps in ISO format
Event descriptions in plain English
Stability scoring (0-100 scale)
Actionable recommendations
System uptime statistics
Memory dump information
Hardware error summaries
Registry key paths and values
Security risk assessments
File existence validation
To modify or extend the server:
Edit source: Modify src/index.ts
Rebuild: Run npm run build
Test: Use MCP inspector or compatible client
Add tools: Follow the MCP SDK patterns for new diagnostic functions
To add new diagnostic capabilities:
Extend the PowerShell script with additional event log queries or registry operations
Add new tool definitions in the ListToolsRequestSchema handler
Implement corresponding handler methods
Update the documentation
Test with appropriate permissions
When adding new PowerShell functionality:
Use ConvertTo-Json for structured output
Handle errors gracefully with try-catch blocks
Test with different execution policies
Validate registry key existence before access
Use appropriate PowerShell cmdlets for registry operations
MIT License - see LICENSE file for details.
Contributions welcome! Please:
Follow TypeScript best practices
Test with Windows 10/11
Document new features
Ensure PowerShell compatibility
Test registry operations carefully
Include proper error handling
Added comprehensive registry diagnostic tools
Registry search functionality
Startup program analysis
System component scanning
Orphaned entry detection
Registry health assessment
Security risk scanning
Enhanced PowerShell execution policy documentation
Initial release
Basic diagnostic capabilities
MCP integration
Stability analysis
PowerShell backend
Analyze startup programs for suspicious entries
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Analyze system stability and provide recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| daysBack | No | Number of days back to analyze (default: 30) |
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.
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.
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.
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.
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.
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.
Find orphaned registry entries pointing to non-existent files
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Get Blue Screen of Death (BSOD) events
| Name | Required | Description | Default |
|---|---|---|---|
| daysBack | No | Number of days back to analyze (default: 7) |
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.
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.
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.
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.
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.
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.
Get an overall registry health assessment
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Get only shutdown and reboot events
| Name | Required | Description | Default |
|---|---|---|---|
| daysBack | No | Number of days back to analyze (default: 7) |
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.
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.
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.
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.
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.
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.
Get comprehensive Windows system diagnostics including crashes, reboots, and system health
| Name | Required | Description | Default |
|---|---|---|---|
| daysBack | No | Number of days back to analyze (default: 7) | |
| detailed | No | Include detailed event information |
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.
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.
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.
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.
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.
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.
Get current system uptime and boot information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Scan the registry for potential security risks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Scan system components like services, drivers, and uninstall entries for issues
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Search the Windows registry by keyword
| Name | Required | Description | Default |
|---|---|---|---|
| maxResults | No | Maximum number of results to return (default: 50) | |
| searchTerm | Yes | Keyword to search for in the registry |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_startup_programsanalyze_system_stabilityfind_orphaned_entriesget_bsod_eventsget_registry_healthget_shutdown_eventsget_system_diagnosticsget_system_uptimescan_security_risksscan_system_componentssearch_registryMost 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
AI agent run monitoring with incident replay and SLA receipts.
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
