Loading ToolBench
MCP server for Windows system diagnostics and crash analysis
This MCP server has 21 tools with moderate schema coverage but significant gaps in descriptions and parameter documentation. Most tools have input schemas with types, but 13 tools have empty or near-empty input schemas (no parameters). Descriptions are present for all tools but range from adequate (hardware_monitor: detailed) to minimal (get_system_uptime, check_admin_status: single sentence). Parameter descriptions are inconsistent, some parameters like 'daysBack' are well-documented, others like those in event_viewer have minimal explanation. No output schemas are documented anywhere. Two destructive tools (kill_process, start_process) lack confirmation or dry-run patterns. Error handling is absent from tool definitions, no guidance on recovery, retryability, or actionable errors. The server prioritizes Windows-specific functionality but lacks LLM-optimized composition patterns.
Analyze startup programs for suspicious entries
Analyze system stability and provide recommendations
Check if the current process is running with administrator privileges
Comprehensive Windows Event Viewer tool that combines search and analysis capabilities. Can enumerate ALL available Windows event logs and search across them for keywords, event IDs, or other criteria, while also providing detailed security analysis
Find orphaned registry entries pointing to non-existent files
Get Blue Screen of Death (BSOD) events
Get an overall registry health assessment
13 tools have empty input schemas (no parameters defined), making their behavior opaque to LLMs. Tools like 'analyze_startup_programs', 'scan_system_components', 'find_orphaned_entries', 'get_registry_health', 'scan_security_risks', 'get_system_uptime', 'check_admin_status' accept no parameters, yet LLMs cannot know whether they are deterministic or configurable. This violates the pattern:tool-description requirement that every tool parameter be described.
No output schemas documented for any tool. LLMs cannot plan downstream operations or extract required fields for chaining. The rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' Without output documentation, agents must guess what each tool returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Get only shutdown and reboot events
Get comprehensive Windows system diagnostics including crashes, reboots, and system health
Get current system uptime and boot information
Get comprehensive usage guide and best practices for the Windows Diagnostics MCP Server
Monitors hardware health including temperatures, fan speeds, drive SMART status, memory health, disk usage, and large files/folders scanning.
Kill a process by its PID or name
List installed applications with optional filters
List running processes with optional filters
Comprehensive driver scanning and analysis tool
Scan the registry for potential security risks
Scan system components like services, drivers, and uninstall entries for issues
Search the Windows registry by keyword
Start a new process from an executable path
Execute WMI queries to retrieve system information
Destructive tools 'kill_process' and 'start_process' lack confirmation, dry-run, or recovery mechanisms. An LLM can terminate arbitrary processes or launch executables without safeguards. The pattern:confirmation-request requires 'Irreversible operations (delete, send, publish) should support a dry-run or confirmation step.'
Parameter descriptions are minimal or absent for many parameters. 'hours' and 'days' in event_viewer are described as 'Search events from last N hours' and 'Search events from last N days' but lack range constraints (e.g., 1 - 365). 'maxEventsPerLog' lacks guidance on impact.
No error handling defined. Tools like 'wmi_query' accept free-form WQL strings but do not document what happens on syntax errors, permission denials, or timeout. LLMs receive no recovery guidance. Pattern:recovery-guide requires 'Error responses must tell the LLM what to do next.'
Tool descriptions are below the baseline average of 194 chars (rubric calibration). 'get_system_uptime' (19 words), 'check_admin_status' (10 words), and 'get_usage_guide' (11 words) fail to explain WHEN to call them or WHAT they return. State WHAT the tool does, WHEN to use it, and any prerequisites.'
No pagination or limit guidance documented. Tools like 'list_processes', 'list_installed_apps', 'event_viewer', and 'scan_drivers' could return hundreds of results, but no cap or pagination mechanism is defined. Rubric requires 'cap results at a reasonable limit (e.g. 20-50) and offer pagination.' Unbounded results risk context window exhaustion.