Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Headless Windows ops over MCP: hidden PowerShell plus in-process SSH, WinRM and SFTP.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"powershell": {
"command": "npx",
"args": [
"-y",
"@imrrd/powershell-mcp"
]
}
}
}Run this in your terminal
claude mcp add powershell -- npx -y @imrrd/powershell-mcpPaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"powershell": {
"command": "npx",
"args": [
"-y",
"@imrrd/powershell-mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"powershell": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@imrrd/powershell-mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified with the GitHub account IMRRD, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.8.0) reached the registry 9 days ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, topo^alpin
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Avalanche bulletins and mountain weather forecasts for any place in the Alps.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
A Model Context Protocol server that gives AI agents real, non-intrusive access to Windows PowerShell.
Most tools that let an agent run Windows commands spawn a visible console window for every call — which steals focus and interrupts whatever you're typing. powershell-mcp runs everything in a hidden process (windowsHide: true / no CreateWindow), captures structured output, enforces hard timeouts, and exposes purpose-built tools for service and system management. Built for running unattended next to a human at the keyboard.
windowsHide: true; foreground focus preservation needs interactive desktop acceptance and is not established by headless CI.{ stdout, stderr, exit_code, duration, timed_out }. Hard timeout with tree-kill. Output is capped so a runaway command can't flood the context.pwsh (PowerShell 7+) and falls back to powershell.exe; override with PWSH_MCP_EXE.The ten execution tools advertise a versioned MCP outputSchema and return the same structuredContent contract (schemaVersion: 1) alongside their original human-readable text. Fields are executionId (per call), transport, target, stdout, stderr, nullable exitCode, durationMs, timedOut, truncation (truncated, nullable limitBytesPerStream), terminationStatus, and detail. terminationStatus is one of completed, nonzero_exit, remote_error, timeout, script_error, cancelled, transport_error, or unknown. Any status other than completed sets MCP isError; this is execution status, not proof that an application operation succeeded. A null exit code never means success. SSH includes a signal or connection error in detail; an unsolicited signal is unknown, not caller cancellation. SFTP includes direction and verified local file size where available. WinRM validates a locally framed invocation result: successful invocation is completed, remote script errors are remote_error, and connection failures are transport_error. Its *local* PowerShell host exit is in detail.localExitCode; remote native exitCode remains null. Missing or truncated frames fail closed. terminationCertainty is root_exited only for an observed local child exit, otherwise unknown; neither status proves descendants or remote execution stopped after a timeout. These results never include authentication options or credential values.
run_program, run_powershell (legacy or strict), winrm_exec, and ssh_exec accept logOutput: true and optional logQuotaBytes (default/max 8 MiB combined stdout and stderr). Disabled by default: no log directory is created without opting in. Raw child output is written separately per stream, independently of the display byte cap. Strict PowerShell persists validated command payload stdout; WinRM also persists its validated remote console stderr. Framing, credentials, stdin, and wrapper diagnostics are never persisted. A result's log contains an unpredictable process-local handle, complete, byte counts, and expiry timestamp. complete: false means producer truncation, quota loss, or a write failure; never interpret it as the entire output. Read through read_output_log with handle, stream, byte offset and length (maximum 65,536 bytes); data is base64, and nextOffset/totalBytes support pagination. delete_output_log removes a log. Handles are available only in this MCP process, never filesystem paths; only the current OS user and SYSTEM have directory ACL access on Windows (0700/0600 on POSIX). The process reserves at most 64 MiB total, expires completed handles one hour after finish on the next log operation (active handles remain reserved), and removes its own files on normal exit. A hard crash may leave private files requiring operator cleanup under the configured POWERSHELL_MCP_LOG_PARENT or TMPDIR, otherwise the OS temp path. Commands can emit secrets: opt-in logs preserve emitted stdout/stderr verbatim, so do not enable logging for sensitive commands. Passwords, stdin and MCP envelopes are never intentionally logged. Framed payload retention is bounded to the larger of the display cap and log quota per stream before JSON/base64 transport. The log quota remains combined across both streams; complete: false reports any producer truncation or log quota loss. Tail mode can therefore produce an incomplete suffix log.
Execution tools accept maxOutputBytes (1–8,388,608, default 1 MiB per stream) and tail (default false: retain the head; true: retain the tail). truncation.stdout and .stderr, when the producer observed stream bytes, report observedBytes, capturedBytes, omittedBytes, and truncated on the original UTF-8 input bytes. capturedBytes + omittedBytes = observedBytes; these are not lengths of pretty-printed text. An incomplete UTF-8 scalar at a head/tail cut is omitted and counted as such. Malformed input is displayed with replacement characters; its captured count refers to original bytes, not the encoded replacement characters. Raw structured stdout/stderr preserve newlines; human-readable formatting may trim whitespace. Wrapper-generated diagnostics are not producer bytes and have no invented stream counts. Some failed/early remote calls cannot report producer-side byte counts. No full logs are persisted by default; opt-in runs return a protected output-log handle. Strict PowerShell and WinRM stream formatted pipeline lines into a fixed-capacity UTF-8 writer, counting all bytes after retention fills. WinRM runs this writer inside the remote script block, before remoting serialization. Direct console stdout joins payload stdout without corrupting framing; remote console stderr has a separate bounded writer and counters. Error summaries retain at most eight shortened records as errors arrive. Producer retention is O(cap), with fixed encoding scratch space; terminal JSON/base64 envelopes and local pipe capture also have finite bounds. This does not bound memory allocated by user scripts, individual objects/lines, PowerShell formatting, or remoting internals. The writer requires Add-Type in each execution runspace; constrained endpoints that forbid compilation are unsupported and fail closed. Counts describe rendered UTF-8 pipeline output, with platform newlines from Out-String -Stream, and UTF-8 console text, rather than original native program bytes. Use run_program for native byte provenance.
Strict/WinRM return payload output only after a validated terminal frame. Timeout, cancellation, malformed frames, or direct OS stdout writes that bypass the console writer fail closed without inventing producer counts or returning frame data as command output; unfinished framed logs are discarded. MCP cancellation requests termination of the local PowerShell process tree and releases its log reservation; it does not prove that remote work or descendants stopped.
| Tool | Description | |
|---|---|---|
run_powershell | Run any PowerShell script/command (hidden). `{ script, cwd?, timeoutMs?, errorPolicy?: "legacy" | "strict", maxOutputBytes?, tail? }` |
runtime_capabilities | Read-only package/protocol version, supported and detected available engines, engine policy (without exposing configured override paths), transports and input/output/timeout limits. Does not return user identity, environment or secrets. | |
run_program | Run a native executable directly (no shell) and capture its stdout/stderr + exit code with direct argument passing. { program, args?, cwd?, timeoutMs?, maxOutputBytes?, tail? } | |
list_services | List services, optional filter wildcard. | |
get_service | Detailed status of one service by name. | |
control_service | start / stop / restart / status a service. | |
system_info | OS, CPU, memory, and per-drive disk summary. | |
ssh_exec | Run a command on a remote host over SSH, fully in-process (no ssh.exe, no WSL — works headless). { host, username, command, port?, privateKeyPath?, passphrase?, password?, timeoutMs?, maxOutputBytes?, tail? } | |
winrm_exec | Run a command on a remote Windows host via PowerShell Remoting (WinRM / Invoke-Command). No SSH server or agent needed on the target. { computerName, command, username?, password?, useSsl?, authentication?, timeoutMs?, maxOutputBytes?, tail? } | |
sftp_upload | Upload a local file to a remote host over SFTP, in-process (ssh2 — no scp.exe/WSL, headless). { localPath, remotePath, host, username, port?, privateKeyPath?, passphrase?, password?, timeoutMs? } | |
sftp_download | Download a remote file to this host over SFTP, in-process. Same params as sftp_upload. |
sftp_upload and sftp_download accept staged: true (default false). The default retains the legacy direct fastPut/fastGet behavior; it does not promise destination preservation or content verification. Staged transfers create an exclusive, unpredictable .part file beside the destination, verify SHA-256 against a readback, and finalize without replacing an existing destination. Upload uses the server's hardlink@openssh.com extension for no-clobber finalization; servers without that capability fail closed rather than falling back to an overwriting rename. Download uses a local hard link for no-clobber finalization. The staging and destination paths must support hard links on the same filesystem; filesystem permissions, server extension behavior and concurrent external writers can still cause failure. Only an exclusively created temporary path is eligible for cleanup; an existing destination is not deleted.
Structured detail adds verification (not_started, failed, or sha256_matched), finalized (true/false, or absent when a remote finalization request was sent but its outcome is unknown), cleanup (not_needed, removed, or failed, or unknown when remote staging may remain), sha256 on verified success, and bytes when the staged copy's size was observed. A cleanup failure after successful finalization may report a failed operation with finalized: true; reconcile the destination and orphaned staging file separately. On timeout or connection loss, the reported cleanup is not proof that remote work stopped or no orphan remains. In particular, do not retry an ambiguous finalization as though finalized: false had been proved. SHA-256 readback checks observed bytes, not an immutable source snapshot: source files must be kept stable by the caller; concurrent mutation outside the observed comparison window is not prevented, and there is no source lock.
Only synthetic loopback SFTP fixtures exercise this feature in the repository; live-server extension behavior, filesystem semantics, and permissions remain unverified and require operator validation before deployment.
Native programs: Historical #1 observed missing native stdout from a hidden PowerShell host for particular executables. This is not universal: on a Windows PowerShell 5.1 local probe (October 20, 2026),
cmd.exe /d /c echo NATIVE_CMD_24,git.exe --version, andnode.exe --versionall produced captured stdout. That probe does not reproduce or refute the originalgh.exe/where.exefailure on its host. Preferrun_program(direct exec) when you need native arguments, exit status and stdout/stderr independent of PowerShell pipeline behavior; userun_powershellfor cmdlets and scripts. Validate the specific executable and host before relying on either path.
Typed inputs: run_powershell accepts engine: "pwsh" | "powershell" (Window
Only the beginning is shown; read the rest in the repo