en es ja ko zh

Super Windows CLI MCP Server

Name: Super Windows CLI MCP Server
Author: Faucet94

by Faucet94

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Servidor MCP de Super Windows CLI

Una bifurcación mejorada del servidor MCP de Windows CLI que proporciona acceso sin restricciones al sistema de entornos Windows a través de una interfaz de línea de comandos (MCP).

Basado en: win-cli-mcp-server por SimonB97.

⚠️ ADVERTENCIA DE SEGURIDAD CRÍTICA ⚠️

Este servidor está diseñado para ejecutarse con privilegios de sistema en Windows. Esto le otorga acceso completo y sin restricciones a todo el sistema operativo, incluyendo todos los archivos, procesos y configuraciones.

NO instale ni ejecute este servidor a menos que comprenda completamente las implicaciones de otorgar acceso a nivel de SISTEMA.
Utilice este servidor SÓLO en entornos de alta confianza donde tenga control total sobre el acceso a la red.
LA SEGURIDAD DE LA RED ES PRINCIPAL: dado que las restricciones a nivel de aplicación son mínimas por diseño, confíe en gran medida en firewalls, segmentación de red y listas de control de acceso estrictas (ACL) para proteger la máquina que ejecuta este servidor.
REVISE LA CONFIGURACIÓN CUIDADOSAMENTE: Preste mucha atención a allowedPaths , blockedCommands y otras configuraciones de seguridad en config.json . Una configuración incorrecta puede exponer fácilmente su sistema.

Utilice este software de forma responsable y bajo su propio riesgo. Los responsables del mantenimiento no se responsabilizan del mal uso ni de las brechas de seguridad derivadas de su uso.

Related MCP server: Windows CLI MCP Server

Características

Acceso completo a entornos de shell de Windows (PowerShell, CMD, Git Bash - configurable).
Ejecución de comandos sin restricciones (configurable mediante config.json ).
Acceso completo al sistema de archivos (configurable a través de config.json ).
Instalación de servicios a nivel de SISTEMA a través de NSSM para persistencia y recuperación automática.
Funciones de recuperación automática del servicio proporcionadas por NSSM.
Controles de enlace de red (previstos, pero gestionados principalmente a nivel de red/firewall).
Se deshabilitó la telemetría de PowerShell para mejorar la privacidad.
Reutilización de procesos para mejorar el rendimiento (para shells).
Tiempos de espera extendidos para operaciones de larga duración (configurables).

Prerrequisitos

Antes de comenzar, asegúrese de tener instalado lo siguiente:

Node.js: Versión 18.0.0 o posterior. Descargar desde nodejs.org . (Incluye npm).
NSSM (Administrador de Servicios No Succionador): Necesario para una instalación fiable del servicio. Descargue la última versión desde nssm.cc.

Instalación (usando NSSM - Recomendado)

Este método instala el servidor como un servicio persistente de Windows que se ejecuta con privilegios de SISTEMA y se inicia automáticamente.

Clonar o descargar:
- Clonar este repositorio: git clone <repository-url>
- O descargue el código fuente .zip y extráigalo a una ubicación adecuada (p. ej., C:\Servers\SuperWinCLIServer ). Evite las carpetas de perfil de usuario.
Lugar NSSM:
- Descargue NSSM desde nssm.cc .
- Extraiga el archivo zip.
- Copie el archivo nssm.exe de la carpeta de arquitectura adecuada ( win32 o win64 ) al directorio raíz de este proyecto (la misma carpeta que install-service.ps1 ).
Instalar dependencias y compilar:
- Abra una terminal (PowerShell o CMD) en el directorio raíz del proyecto.
- Ejecutar: npm install
- Este comando instala los paquetes Node.js necesarios y ejecuta automáticamente npm run build para compilar el código TypeScript en la carpeta dist .
Configurar config.json :
- Copiar: haga una copia de config.sample.json y nómbrela config.json en el directorio raíz del proyecto.
- Editar: Abra config.json y revise y modifique cuidadosamente la configuración:
  - security.allowedPaths : ¡CRÍTICO! Cambie las rutas de ejemplo a los directorios a los que el servidor necesita acceder. Por seguridad, sea lo más específico posible. Si no está seguro, comience con el directorio del proyecto (p. ej., "C:\\Servers\\SuperWinCLIServer" ; recuerde las barras invertidas dobles \\ ). El servicio se ejecuta como SYSTEM, por lo que las rutas deben ser válidas para esa cuenta.
  - security.blockedCommands / blockedArguments : Revisa las listas predeterminadas. Agrega o elimina comandos/argumentos según tu política de seguridad.
  - shells : habilitar/deshabilitar shells (PowerShell, CMD, Git Bash) y verificar la ruta command (especialmente para Git Bash).
  - ssh : configure si desea utilizar la función de ejecución SSH (deshabilitada de manera predeterminada).
- Guarde el archivo config.json .
Ejecutar script de instalación:
- Abra PowerShell como administrador .
- Navegue al directorio raíz del proyecto ( cd C:\Servers\SuperWinCLIServer ).
- Ejecute el script de instalación: .\install-service.ps1
- Este script utiliza NSSM para instalar y configurar el servicio MCPServer para ejecutar node.exe dist/index.js como LocalSystem y comenzar automáticamente.
Verificar el estado del servicio:
- En la misma ventana administrativa de PowerShell, ejecute: Get-Service MCPServer
- El estado debe ser Running . Si está " Stopped , revise los registros de NSSM o el Visor de eventos de Windows (registros de aplicación y del sistema) para detectar errores.

Detalles de configuración ( `config.json` )

security :
- maxCommandLength : Máximo de caracteres permitidos en una cadena de comando.
- blockedCommands : Matriz de nombres de comandos (sin extensión) para bloquear (sin distinción entre mayúsculas y minúsculas).
- blockedArguments : Matriz de argumentos exactos a bloquear (sin distinguir entre mayúsculas y minúsculas).
- allowedPaths : Configuración crucial. Matriz de rutas absolutas. Si restrictWorkingDirectory es verdadero, los comandos solo se pueden ejecutar si su directorio de trabajo comienza con una de estas rutas. Las rutas se comparan sin distinción entre mayúsculas y minúsculas después de la normalización. Use barras invertidas dobles (p. ej., "C:\\Tools\\Scripts" ).
- restrictWorkingDirectory : Booleano. Si es verdadero, se aplica la comprobación de allowedPaths para el directorio de trabajo. Se recomienda mantenerlo true .
- logCommands : Booleano. Si es verdadero, los comandos ejecutados y su salida (truncada) se almacenan en memoria (hasta maxHistorySize ").
- maxHistorySize : Número máximo de comandos que se mantendrán en el historial en memoria.
- commandTimeout : Segundos antes de que un comando en ejecución se elimine automáticamente.
- enableInjectionProtection : Booleano. Si es verdadero, intenta bloquear los operadores de shell ( & , | , ; , etc., definidos por shell) en los comandos.
shells : configura los shells locales disponibles (powershell, cmd, gitbash).
- enabled : Booleano. Permite el uso de este shell.
- command : Ruta al ejecutable del shell.
- args : Matriz de argumentos predeterminados pasados al shell antes del comando del usuario.
- blockedOperators : Matriz de cadenas/caracteres para bloquear dentro de los comandos para este shell específico (se usa si enableInjectionProtection es verdadero).
ssh : configura la ejecución remota de comandos a través de SSH.
- enabled : Booleano. Habilita las herramientas ssh_execute y ssh_disconnect .
- connections : Objeto que contiene configuraciones de conexión con nombre (host, puerto, nombre de usuario, contraseña/privateKeyPath).
Fusión de la configuración: Al cargar config.json , si contiene una sección security o shells , dicha sección reemplaza la configuración predeterminada. No se fusionan campos individuales dentro de las secciones security o shells . La sección ssh se fusiona de forma más granular. Asegúrese de que su config.json incluya todos los campos necesarios para estas secciones si las personaliza.

Gestión de servicios (NSSM)

Una vez instalado a través de install-service.ps1 , puede administrar el servicio utilizando herramientas estándar de Windows o comandos NSSM desde un PowerShell/CMD administrativo en el directorio del proyecto:

Inicio: Start-Service MCPServer o .\nssm.exe start MCPServer
Detener: Stop-Service MCPServer o .\nssm.exe stop MCPServer
Reiniciar: Restart-Service MCPServer o .\nssm.exe restart MCPServer
Estado: Get-Service MCPServer o .\nssm.exe status MCPServer
Editar configuración (avanzado): .\nssm.exe edit MCPServer (abre el editor de GUI de NSSM)
Ver configuración: .\nssm.exe dump MCPServer

Desinstalación (NSSM)

Abra PowerShell como administrador .
Navegue hasta el directorio raíz del proyecto.
Ejecute el script de desinstalación: .\uninstall-service.ps1
Esto utiliza NSSM para detener y eliminar el servicio MCPServer .

Ejecución alternativa (manual/depuración)

Puede ejecutar el servidor directamente sin instalarlo como un servicio para fines de prueba o depuración:

Asegúrese de haber ejecutado npm install .
Asegúrese de que config.json exista y esté configurado.
Abra una terminal normal (PowerShell/CMD) en la raíz del proyecto.
Ejecutar: npm run start
El servidor se ejecutará en primer plano. Presione Ctrl + C para detenerlo.

Licencia

Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.

Available Tools

4 tools

execute_commandB

Execute a command in the specified shell (powershell, cmd, or gitbash)

Example usage (PowerShell):

{
  "shell": "powershell",
  "command": "Get-Process | Select-Object -First 5",
  "workingDir": "C:\Users\username"
}

Example usage (CMD):

{
  "shell": "cmd",
  "command": "dir /b",
  "workingDir": "C:\Projects"
}

Example usage (Git Bash):

{
  "shell": "gitbash",
  "command": "ls -la",
  "workingDir": "/c/Users/username"
}

ParametersJSON Schema

Name	Required	Description
`command`	Yes	Command to execute
`shell`	Yes	Shell to use for command execution
`workingDir`	No	Working directory for command execution (optional)

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It gives examples but does not mention return values, exit codes, error handling, side effects, environment specifics, or security implications. For a command execution tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening one-sentence description is concise and front-loaded. The three examples are redundant in structure but serve to illustrate cross-shell syntax. Each sentence earns its place, though the examples could be trimmed to one or two without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that executes arbitrary system commands, there is no mention of output format, timeouts, working directory defaults, or safety considerations. The presence of sibling ssh_execute suggests a need to clarify local vs remote execution, which is absent. The examples help but do not fill all gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of parameters, but the description adds value through concrete examples showing valid shell values, command syntax, and workingDir formatting (e.g., Windows paths vs Git Bash paths). This enhances understanding beyond the schema's terse descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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 specified shell (powershell, cmd, or gitbash), which is a specific verb+resource. It is distinguishable from siblings like get_command_history and ssh_execute, though it does not explicitly call out these differences. The mention of the shell options adds specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as ssh_execute (remote execution) or get_command_history. The examples imply usage but do not provide context, prerequisites, or exclusions. This is a clear gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_command_historyA

Get the history of executed commands

Example usage:

{
  "limit": 5
}

Example response:

[
  {
    "command": "Get-Process",
    "output": "...",
    "timestamp": "2024-03-20T10:30:00Z",
    "exitCode": 0
  }
]

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of history entries to return (default: 10, max: 1000)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It adds transparency by showing a detailed example response with fields (command, output, timestamp, exitCode), which clarifies the return format. However, it does not explicitly state whether history is session-scoped, how results are ordered, or that it has no side effects. Given the absence of annotations, there are notable but not critical gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a single opening sentence plus two compact JSON examples. The purpose is front-loaded, and every element adds value—the example usage demonstrates the parameter, and the example response shows the expected output structure. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter, no-output-schema tool, the description is quite complete: it states the purpose, shows how to invoke it, and provides a representative response. Minor omissions like ordering or session scope are not critical for a list-history tool. The example response effectively substitutes for an output schema, making the tool actionable for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the 'limit' parameter with default (10) and max (1000) values, providing 100% coverage. The description's example usage (limit: 5) reinforces the parameter but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource statement: 'Get the history of executed commands'. It distinguishes itself from sibling tools like execute_command (execution) and ssh_execute (remote execution) by focusing specifically on retrieval of prior commands. The example response reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage context: to retrieve previously executed commands, with an example showing the optional limit parameter. It does not explicitly state when not to use it, but the purpose is self-evident and no competing history tools exist among siblings. No explicit exclusions are given, but this is clearly a read-only counterpart to the execution siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ssh_disconnectA

Disconnect from an SSH server

Example usage:

{
  "connectionId": "raspberry-pi"
}

Use this to cleanly close SSH connections when they're no longer needed.

ParametersJSON Schema

Name	Required	Description	Default
`connectionId`	Yes	ID of the SSH connection to disconnect

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden. It mentions 'cleanly close' but doesn't disclose side effects like what happens to associated sessions, idempotency, or error behavior. It's minimally adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and includes a practical JSON example, which helps the agent. It repeats the concept slightly ('Disconnect' and 'close SSH connections'), but overall it's well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description is adequate. It provides an example and clear use case. It doesn't cover errors or edge cases, but given the low complexity, this is not a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the parameter described as 'ID of the SSH connection to disconnect'. The example usage adds an illustrative value (raspberry-pi) but doesn't add semantic meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Disconnect' and the resource 'SSH connection/server', which distinguishes it from siblings like ssh_execute and execute_command. The example usage reinforces the exact action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says 'when they're no longer needed', providing clear context for when to use this tool. It doesn't explicitly mention alternatives or when not to use, but the sibling tool names imply the distinction, so a slight deduction is warranted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ssh_executeA

Execute a command on a remote host via SSH

Example usage:

{
  "connectionId": "raspberry-pi",
  "command": "uname -a"
}

Configuration required in config.json:

{
  "ssh": {
    "enabled": true,
    "connections": {
      "raspberry-pi": {
        "host": "raspberrypi.local",
        "port": 22,
        "username": "pi",
        "password": "raspberry"
      }
    }
  }
}

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	Command to execute
`connectionId`	Yes	ID of the SSH connection to use

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions that SSH must be enabled in config.json and gives an example connection, which is useful. However, it does not disclose the command execution behavior (e.g., output format, error handling, potential destructive side-effects) or that it uses the specified password for authentication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured and efficient, with a one-sentence purpose followed by illustrative JSON examples. The config block is large but necessary to show the setup requirements. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain what the tool returns or what 'execute' entails. It does neither, though it does provide configuration context. For a command execution tool, the lack of mention of output or error behavior leaves a moderate gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema descriptions are minimal ('Command to execute', 'ID of the SSH connection to use'). The description adds meaningful value by showing an example usage and the config structure, clarifying that connectionId refers to a key in the 'connections' object and command is a shell string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Execute a command on a remote host via SSH', using a specific verb and resource. It distinguishes itself from sibling tools like ssh_disconnect (manage connection) and get_command_history (retrieve history).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete example and configuration requirement, implying when to use the tool (when you have a configured SSH connection and need to run a command). However, it does not explicitly state when to use it over alternatives like execute_command, nor does it provide exclusion criteria.

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.

4 tool updatesv1.0.0Aug 15, 2025
- First observedexecute_command
- First observedget_command_history
- First observedssh_disconnect
- First observedssh_execute

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-04-18 10:35 across 4 tools

Disambiguation3/5

The tools have some overlap in purpose that could cause confusion. Both execute_command and ssh_execute run commands, differing only in local vs. remote execution, which might lead to misselection if the agent doesn't carefully note the distinction. However, get_command_history and ssh_disconnect are clearly distinct, and the descriptions help clarify the differences.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern throughout (e.g., execute_command, get_command_history, ssh_disconnect, ssh_execute), which is predictable and readable. There are minor deviations, such as the use of 'disconnect' versus 'execute' in the SSH tools, but overall, the pattern is maintained.

Tool Count3/5

With 4 tools, the count is borderline for the server's purpose as a 'Super Windows CLI MCP Server'. It feels thin, lacking coverage for common CLI operations like file management, process control, or network utilities, which might be expected in such a domain. However, it's not severely under-scoped.

Completeness2/5

There are significant gaps in the tool surface for a Windows CLI server. It lacks basic operations like listing files, managing processes, or handling network configurations, and the SSH tools seem like an add-on rather than core functionality. This incompleteness will likely cause agent failures when trying to perform common CLI tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

ReMCP AOAuth
site.remcp
Securely control computers you explicitly pair through files, terminals, processes, screenshots, desktop UI/input, clipboard, browser automation, diagnostics, and document tools.
Command Line File Systems OS Automation
101
Remote Desktop CommanderOAuth
app.desktopcommander
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Shell Access OS Automation
2167
browser-ssh
com.browserssh
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Shell Access File Systems
2
SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
215

Related MCP Servers

Super Windows CLI MCP Server
Shell Access OS Automation Command Line
delorenj
A
license
B
quality
C
maintenance
An enhanced Windows CLI MCP server providing unrestricted system access capabilities, designed for trusted environments with full system access requirements.
Updated 2 years ago (2025-01-19 18:37 UTC)
4
1,570 npm
7
MIT
Windows CLI MCP Server
Shell Access Command Line OS Automation
simon-ami
A
license
B
quality
F
maintenance
A Model Context Protocol server that provides secure command-line access to Windows systems, allowing MCP clients like Claude Desktop to safely execute commands in PowerShell, CMD, and Git Bash shells with configurable security controls.
Updated a year ago (2025-08-07 14:47 UTC)
9
1,570 npm
267
MIT
Windows CLI MCP Server
Shell Access Command Line
s2005
A
license
A
quality
B
maintenance
Enables secure command-line interactions on Windows systems with support for PowerShell, CMD, Git Bash, and WSL shells, providing controlled file access, command execution, and configurable security restrictions.
Updated 2 months ago (2026-08-23 21:22 UTC)
6
14 npm
4
MIT
Windows CLI MCP Server
Shell Access Command Line OS Automation
quanticsoul4772
A
license
B
quality
D
maintenance
Enables secure command-line interactions on Windows systems through PowerShell, CMD, and Git Bash, with support for SSH remote connections, SFTP file transfers, system monitoring, and configurable security controls including command blocking and path restrictions.
Updated 4 months ago (2026-06-09 23:58 UTC)
34
2
MIT

Servidor MCP de Super Windows CLI

⚠️ ADVERTENCIA DE SEGURIDAD CRÍTICA ⚠️

Características

Prerrequisitos

Instalación (usando NSSM - Recomendado)

Detalles de configuración ( config.json )

Gestión de servicios (NSSM)

Desinstalación (NSSM)

Ejecución alternativa (manual/depuración)

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Detalles de configuración ( `config.json` )