pwsh-exec
Click on "Deploy 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., "@pwsh-execrun 'Get-Date'"
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.
pwsh-exec
A minimal, transparent PowerShell 7 MCP for Windows — one tool: run a command, get raw exit code / stdout / stderr back.
pwsh-exec is a minimal, transparent PowerShell 7 MCP server for Windows. It exposes a single tool, run_command, that runs a command in a fresh pwsh process and returns the raw exit_code, stdout, and stderr — nothing parsed, filtered, or reformatted.
One tool, three inputs —
command,timeout(seconds), optionalworking_directory.Transparent — exit code + stdout + stderr returned verbatim, errors and all.
Stateless — every call is a new process; no session state persists.
Bounded — 1–300 s timeout per call; on timeout the whole process tree is killed.
Windows-hardened — UTF-8 output on any locale, PATH read fresh from the registry, no stdin hangs.
Not for — persistent shells, admin-elevated tasks, or long-running / background jobs.
It gives any AI agent on Windows a real terminal: you send a command, you get back exactly what the terminal produced.
Status — stable & complete
Feature-complete and stable. One tool, a frozen v1.0.0 API, 38 passing tests, in daily use driving real agent work since April 2026 with no known bugs. Reproducible bugs get fixed; the scope stays intentionally small — it does one thing.
Related MCP server: powershell-mcp
Requirements
Windows
PowerShell 7 (
pwsh) onPATH— this is the modern cross-platform PowerShell, not the built-in Windows PowerShell 5.1 (powershell.exe). Install it viawinget install Microsoft.PowerShellor from the official install guide.uv — provides the
uvxrunner used below.
Install
No clone required — uvx fetches and runs it on demand. Register it with your MCP client (stdio transport):
Any MCP client
Use this as the server's launch command:
uvx pwsh-execClaude Desktop
Edit claude_desktop_config.json:
{
"mcpServers": {
"pwsh-exec": {
"command": "cmd",
"args": ["/c", "uvx", "pwsh-exec"]
}
}
}The
cmd /cwrapper is recommended on Claude Desktop: as an Electron app it has no console of its own, and launching a console program directly can leave child processes (pwsh → git and other external.exes) without a working console — flickering windows, lost stdout, PATH lookups failing.cmd.exeacquires the hidden console first and every child inherits it. This is the same pattern Desktop Commander and other Windows MCP servers use.
The tool: run_command
Parameter | Type | Required | Description |
| string | yes | The PowerShell command or script to run. |
| integer | yes | Timeout in seconds (not milliseconds). 1–300. |
| string | no | Absolute path. Defaults to the resolved working directory (see Configuration). |
The output is plain text: the exit code first, then labelled stdout and stderr sections (empty ones still show, so the two streams are never ambiguous), then a diagnostic footer with a timestamp and elapsed time.
For example, calling run_command with command: "git status" returns the raw git output, untouched:
exit_code: 0
stdout:
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: app.py
no changes added to commit (use "git add" and/or "git commit -a")
stderr:
(empty)
[2026-06-13 08:43:11 | 625ms]Nothing is summarised or filtered. A non-zero exit code, a syntax error written to stderr, an empty result — all of it comes back as the terminal produced it. Output longer than 500 lines per stream is trimmed to the first and last 250 lines so it never floods the context window.
Why it's robust on Windows
Running a shell on Windows from a host process is full of small traps. pwsh-exec handles them so the agent doesn't have to:
UTF-8 on any locale — output encoding is forced to UTF-8 end to end, so text isn't mangled even on non-English Windows. It was hardened on zh-CN / GBK systems, where these encoding bugs bite hardest; the fix is universal.
Always-fresh PATH — User-scope environment variables are read from the registry on every call, so CLIs you installed after the host started are still found (and
REG_EXPAND_SZvalues like%USERPROFILE%\...are expanded correctly).Clean process-tree kills — on timeout the whole tree is terminated (
pwshplus any children it spawned, e.g.node,python), leaving no orphans.No stdin hangs — stdin is detached, so tools that probe it (git and other MSYS2 programs) don't deadlock.
Sane truncation — very long output is head+tail trimmed instead of blowing up the model's context.
What it's not for
The small scope is the design. pwsh-exec deliberately does not do:
Persistent sessions — each call is stateless;
cdand variables don't carry over. Passworking_directory, or combine dependent steps into one command.Admin-elevated tasks — it runs as the host user, with no elevation.
Long-running / background jobs — the hard cap is 300 s and calls are synchronous. Installers, large builds, dev servers, and watchers are out of scope.
Configuration
working_directory defaults to a resolved directory, chosen in this order (highest priority first):
The
working_directoryargument passed on the call.The
PWSH_EXEC_DEFAULT_DIRenvironment variable, if set.The built-in fallback:
%TEMP%\pwsh-exec.
To change the default, set PWSH_EXEC_DEFAULT_DIR in your MCP client's config:
{
"mcpServers": {
"pwsh-exec": {
"command": "cmd",
"args": ["/c", "uvx", "pwsh-exec"],
"env": { "PWSH_EXEC_DEFAULT_DIR": "D:\\scratch" }
}
}
}An unset or blank value falls back to the built-in default. The default lives under %TEMP% (its own subfolder, so you can wipe it wholesale) rather than scattering files into the shared temp directory.
License
MIT © 2026 Jason26214
Available Tools
1 toolrun_commandA
Execute a command in a new PowerShell (pwsh 7) process. Stateless — no state persists between calls.
NOT for long-running tasks. Hard cap is 300 seconds (5 minutes); there is no background mode. Do NOT use for: installers (Ollama, VS, .NET SDK, etc.), large builds, package managers that may exceed 5 minutes (npm install on cold cache, pip install torch, etc.), dev servers, or anything interactive.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| timeout | Yes | Timeout in SECONDS (not milliseconds). Integer between 1 and 300. | |
| working_directory | No | %TEMP%\\pwsh-exec |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: new process, statelessness, hard timeout of 300 seconds, no background mode. The description also forbids interactive processes and certain types of commands. It does not mention error handling or output format, but the output schema likely covers returns. Overall, it is fairly transparent.
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: a single-sentence purpose followed by bullet-point limitations. Every sentence adds value, with no redundancy. The critical information is front-loaded, and the formatting (newlines, bullet dashes) aids readability.
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 command execution tool with 3 parameters and an output schema, the description covers statelessness, timeout, and forbidden uses. However, it lacks details on output format (e.g., stdout/stderr), error handling, and security considerations. Given the complexity, some additional context would be beneficial, but the core functionality is adequately described.
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 low (33%), meaning only the 'timeout' parameter has a description in the schema. The tool description adds implicit context about timeout (the 300-second cap) but does not explain the 'command' parameter format or the 'working_directory' parameter beyond the schema's default. This is insufficient compensation for the coverage gap.
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 executes a command in a new PowerShell (pwsh 7) process and is stateless. It uses a specific verb ('Execute') and resource ('command in a new PowerShell process'), making the purpose unambiguous. No sibling tools exist, so differentiation is not needed.
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 explicit negative usage guidelines, listing scenarios where the tool should not be used (long-running tasks, installers, large builds, etc.). However, it does not suggest alternative tools for those cases (no siblings listed), so while the guidance is clear, it lacks positive direction. This earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.1- First observed
run_command
TDQS
Scored across 1 tool
With only one tool, there is no risk of confusion or overlap. The single tool has a clear, distinct purpose.
The single tool name 'run_command' follows a clear verb_noun pattern, consistent with itself.
One tool is minimal but appropriately scoped for executing commands in a stateless manner. The server's purpose is narrow, so the tool count fits well.
The tool covers the core functionality of running commands. While features like background execution or state management are missing, they are explicitly excluded, so the surface is complete for its intended use.
Maintenance
Related MCP Connectors
Execute PowerShell commands securely with controlled timeouts and input validation. Retrieve syste…
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Run Python code in a secure sandbox without local setup. Declare inline dependencies and execute s…
Remote shell and detached long-running jobs on your own machines — no SSH, open ports or VPN.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables remote Windows server administration and troubleshooting via WinRM and SSH PowerShell protocols.6-
- AlicenseAqualityAmaintenanceEnables AI agents to run PowerShell commands and manage Windows services without intrusive console windows, while also supporting remote execution via SSH and WinRM.10116 npmMIT
- AlicenseBqualityCmaintenanceEnables running PowerShell and CMD commands on Windows hosts over WinRM, with multi-host inventory management.11MIT
- AlicenseNot gradedqualityCmaintenanceEnables Windows-native developer orchestration for Claude Code and Codex with PowerShell discovery, capability routing, safety-gated execution, package management, and sandbox-based isolation.MIT