Loading ToolBench
MCP server for Windows system administration: Services, Event Viewer, Task Scheduler, and more
26 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention well (diagnose_service, system_health, events_query). Descriptions average ~120 chars, meeting baseline. However, several tools lack output schema documentation, parameter descriptions are sometimes generic, and error handling guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Risk field present in metadata but not exposed to LLM via tool annotations.
Query the audit log. Returns recent operations performed through the MCP server.
Cancel a pending destructive action.
Get the current safety and audit configuration for windows-admin-mcp.
Reload configuration from config.json file. Use after editing the config file.
Confirm a pending destructive action. When safety.requireConfirmation is enabled, destructive operations (kill, stop, delete, bulk) return a confirmationId instead of executing immediately. Call this tool with that ID to proceed.
Diagnose why a Windows service is not working. Runs a chain of checks (status, config, event logs, dependencies, optional port check) and returns a structured report with a hypothesis.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata. LLM cannot see which tools are safe vs destructive without reading descriptions.
Output schemas not documented in tool definitions. LLM cannot plan downstream calls or extract required fields (e.g., what does diagnose_service return? What fields does system_health include?).
Error handling lacks recovery guidance. Tools do not document what errors are retryable, user-fixable, or fatal. No examples of error messages or suggested next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Analyze error event trends over time. Shows error counts per hour to identify if error rate is growing, shrinking, or stable.
Explain a Windows Event ID — what it means, common causes, and suggested fixes.
List available Windows Event Viewer log names.
Query Windows Event Viewer logs. Filter by log name, level, source, time range, and keyword.
List event sources/providers for a specific log.
Get a summary of recent events grouped by level for a specific log.
Poll for new Critical/Error events since the last check (or since a given timestamp). Returns only the delta. Useful for periodic monitoring.
Check if a TCP port is open on a remote host.
List active TCP network connections, optionally filtered by state or port.
Perform a DNS lookup for a given name.
Test network connectivity to a host using ICMP ping.
List all pending destructive actions awaiting confirmation.
Get detailed information about a specific process by name or PID.
Kill (terminate) a process by name or PID. Protected processes (lsass, csrss, etc.) are blocked. If safety.requireConfirmation is enabled, returns a confirmationId.
List processes sorted by CPU, Memory, or Name. Optionally filter by name pattern.
Show which processes are holding which TCP ports (listening and established connections).
Perform an action (Start, Stop, Restart) on all Windows services matching a name pattern. Subject to limits.maxBulkOperations and confirmation flow.
Check for auto-start services that are not running. Returns a list of services that should be running but are stopped or in a degraded state.
Detect what changed on the system in the last N hours: new services installed, new scheduled tasks created, and services that changed state.
Get a full system health overview in a single call: CPU, memory, disk, top processes, recent errors, and stopped auto-start services.
Parameter descriptions sometimes generic or missing context. E.g., 'namePattern' in processes_list lacks guidance on wildcard syntax; 'logName' in events_query lacks examples of valid log names.
Confirmation flow (confirm_action, cancel_action, pending_actions) is well-designed but lacks documentation of the full workflow. LLM may not understand when confirmation is required or how to handle confirmationId lifecycle.