Loading ToolBench
A comprehensive Windows system diagnostics MCP server providing tools for hardware monitoring, system information, event logs, processes, services, GPU/DirectX info, and sensor data collection.
Strong foundation with well-structured tool definitions, clear naming conventions, and comprehensive parameter schemas. All 12 tools follow verb_noun pattern (get_*, list_*, start_*, stop_*). Descriptions are detailed (100-300 chars typical) and explain WHAT, WHEN, and prerequisites. Input schemas include types and descriptions for all parameters. Error handling via ToolError enum with codes, messages, hints, and retryability flags. Main gaps: output schemas not explicitly documented in source; no tool annotations (readOnlyHint/destructiveHint); parameter constraints (enums, ranges) could be more formal in schema definitions; no pagination support visible for list tools despite potentially large result sets.
Get system boot, shutdown, and crash events. Returns timestamps, event types (Normal/Shutdown/UnexpectedShutdown/BlueScreen/Sleep/Wake), and durations. Default: last 24 hours, max 100 results.
Report available tools, current platform, elevation status, and parameter hints for each tool. Call this first to understand what diagnostics are available.
Get DirectX diagnostic information including DirectX version, display adapters (card name, manufacturer, VRAM, driver version, feature levels, WDDM model, HDR support), and sound devices. Uses dxdiag which is built into Windows.
Get NVIDIA GPU information including model name, driver version, VRAM usage, temperature, utilization, power draw, and performance state. Requires nvidia-smi (included with NVIDIA GPU drivers).
Get hardware sensor monitoring results with min/max/average/current statistics per sensor. Supports filtering by hardware type and sensor type. Data is read from disk, so results survive server crashes. Requires start_sensor_monitoring to have been called at least once.
Output schemas not explicitly documented in source code. While ToolResponse<TData> envelope is defined with metadata (warnings, totalAvailable, elapsedMs, platform, isElevated), the specific data payload types for each tool are not visible in provided code.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema definitions. While risk classification (READ_ONLY vs WRITE) is documented in metadata, MCP tool annotations are not present in the tool registration.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Query Windows services by name pattern and status filter. Returns service name, display name, description, status, start type, account, executable path, dependencies, PID, and memory usage. Default max 100 results, max 500.
Get a snapshot of system hardware and OS information including hostname, OS version, CPU, memory, uptime, and disk volumes.
List available event log sources on this system. Returns source names, whether they require elevation, and approximate record counts.
List top processes by CPU or memory usage. Supports sorting by cpu/memory/name, minimum thresholds, and result limits. Default: top 25 by CPU, max 100.
Search system event log entries. Accepts time range (default: last 24h), severity filter (Verbose/Information/Warning/Error/Critical), source name, keyword search, and max results (default 100, max 500). Returns normalized entries with timestamp, severity, source, eventId, message. Some sources (e.g., Security) require elevation.
Start background hardware sensor monitoring. Collects temperature, fan speed, voltage, clock, load, and power data from CPU, GPU, motherboard, memory, and storage at a configurable interval. Data is persisted to disk and survives crashes. Call get_sensor_data to retrieve aggregated results.
Stop background hardware sensor monitoring. Collected data remains available via get_sensor_data.
List tools (list_log_sources, list_top_processes, query_system_log) accept maxResults parameters but no pagination cursor or offset mechanism visible. Large result sets could exhaust context window.
Parameter constraints (enums, min/max ranges) are documented in descriptions but not formalized in JSON Schema. E.g., 'severity' in query_system_log lists valid values in description text rather than as enum constraint.
No explicit confirmation or dry-run pattern for write operations (start_sensor_monitoring, stop_sensor_monitoring). Agents cannot preview side effects before committing.