Summary

Execution and the check before it are separate calls, so the destructive path takes two.

The read tools cover exactly what you would look at before running anything — system information, environment, processes, disk usage, directory contents — and execute_command's own description points the caller at them first. Dangerous execution routes through confirm_command with a confirmation_id and an explicit confirm, so a badly worded single call does not reach the shell. What does run, runs with whatever the WSL session already has; the gate governs the second call, not the permissions.

What it is

A WSL command surface with the inspection tools on one side, execute_command on the other, and a confirmation step in between for anything dangerous.

What you get

WSL system information, and the environment variables with an optional filter
Running processes, filterable, and disk space for a given path
Directory contents, with a details view when the listing alone is not enough
Commands executed inside WSL with a working_dir and a timeout
A confirmation gate — confirm_command takes a confirmation_id and an explicit confirm before a dangerous command execution goes ahead

Requirements

A WSL distribution on the host for the tools to read and run inside. Nothing is configured — no account, no key.

Setup effort

One command — npx -y mcp-wsl-exec