Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Descripción del creador (original en inglés)
Headless Windows ops over MCP: hidden PowerShell plus in-process SSH, WinRM and SFTP.
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
Necesitas
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Abre Claude Desktop → Settings → Developer → Edit Config y pega esto en claude_desktop_config.json
{
"mcpServers": {
"powershell": {
"command": "npx",
"args": [
"-y",
"@imrrd/powershell-mcp"
]
}
}
}Ejecuta esto en tu terminal
claude mcp add powershell -- npx -y @imrrd/powershell-mcpPégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"powershell": {
"command": "npx",
"args": [
"-y",
"@imrrd/powershell-mcp"
]
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"powershell": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@imrrd/powershell-mcp"
]
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Este se ejecuta en tu computadora, y ChatGPT solo puede conectarse a servidores en internet. Elige otra app.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Se ejecuta en tu computadora; la lista de herramientas aparece en tu app de IA después de instalarlo.
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 6 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub IMRRD, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Este se ejecuta en tu computadora; no hay endpoint en internet
Se ejecuta en tu computadora y usa ajustes locales en su lugar
Se ejecuta en tu computadora; solo podemos leer listas de herramientas de endpoints en internet
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.
Se ejecuta en tu computadora. Tu app de IA lo inicia cuando hace falta, y los datos no pasan por los servidores del creador (a menos que el propio servidor llame a un servicio en línea).
El repo de GitHub cambió por última vez –, y la última versión (0.8.0) llegó al registro hace 9 días.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. También necesitas Node.js en tu computadora.
En la misma categoría: Spec Driven Development, Remote Desktop Commander, Symantec Cloud DLP AIops
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
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.
Governed Symantec Cloud DLP — 14 MCP tools, read-only with audit.
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
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
Solo se muestra el principio; lee el resto en el repo