Skip to main content
Glama
enesjakozh
Faucet94

Super Windows CLI MCP Server

by Faucet94
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Super Windows CLI MCP Server

An enhanced fork of the Windows CLI MCP Server providing unrestricted system access to Windows environments via a command-line interface (MCP).

Based on: win-cli-mcp-server by SimonB97.

⚠️ CRITICAL SECURITY WARNING ⚠️

This server is designed to run with SYSTEM-level privileges on Windows. This grants it complete and unrestricted access to the entire operating system, including all files, processes, and configuration settings.

  • DO NOT install or run this server unless you fully understand the implications of granting SYSTEM-level access.

  • ONLY use this server in highly trusted environments where you have full control over network access.

  • NETWORK SECURITY IS PARAMOUNT: Since application-level restrictions are minimal by design, rely heavily on firewalls, network segmentation, and strict access control lists (ACLs) to protect the machine running this server.

  • REVIEW THE CONFIGURATION CAREFULLY: Pay close attention to allowedPaths, blockedCommands, and other security settings in config.json. A misconfiguration can easily expose your system.

Use this software responsibly and at your own risk. The maintainers assume no liability for misuse or security breaches resulting from its use.

Related MCP server: Windows CLI MCP Server

Features

  • Complete access to Windows shell environments (PowerShell, CMD, Git Bash - configurable).

  • Unrestricted command execution (configurable via config.json).

  • Full file system access (configurable via config.json).

  • SYSTEM-level service installation via NSSM for persistence and auto-recovery.

  • Automatic service recovery features provided by NSSM.

  • Network binding controls (intended, but primarily managed at the network/firewall level).

  • Disabled PowerShell telemetry for enhanced privacy.

  • Process reuse for performance (for shells).

  • Extended timeouts for long-running operations (configurable).

Prerequisites

Before you begin, ensure you have the following installed:

  1. Node.js: Version 18.0.0 or later. Download from nodejs.org. (Includes npm).

  2. NSSM (Non-Sucking Service Manager): Required for reliable service installation. Download the latest version from nssm.cc.

Installation (Using NSSM - Recommended)

This method installs the server as a persistent Windows service that runs with SYSTEM privileges and starts automatically.

  1. Clone or Download:

    • Clone this repository: git clone <repository-url>

    • Or download the source code .zip and extract it to a suitable location (e.g., C:\Servers\SuperWinCLIServer). Avoid user profile folders.

  2. Place NSSM:

    • Download NSSM from nssm.cc.

    • Extract the zip file.

    • Copy the nssm.exe file from the appropriate architecture folder (win32 or win64) into the root directory of this project (the same folder as install-service.ps1).

  3. Install Dependencies & Build:

    • Open a terminal (PowerShell or CMD) in the project's root directory.

    • Run: npm install

    • This command installs necessary Node.js packages and automatically runs npm run build to compile the TypeScript code into the dist folder.

  4. Configure config.json:

    • Copy: Make a copy of config.sample.json and name it config.json in the project's root directory.

    • Edit: Open config.json and carefully review and modify the settings:

      • security.allowedPaths: CRITICAL! Change this from the sample paths to the actual directories the server needs access to. For security, be as specific as possible. Start with the project directory itself if unsure (e.g., "C:\\Servers\\SuperWinCLIServer" - remember double backslashes \\). The service runs as SYSTEM, so paths must be valid for that account.

      • security.blockedCommands / blockedArguments: Review the default lists. Add or remove commands/arguments based on your security policy.

      • shells: Enable/disable shells (PowerShell, CMD, Git Bash) and verify the command path (especially for Git Bash).

      • ssh: Configure if you intend to use the SSH execution feature (disabled by default).

    • Save the config.json file.

  5. Run Installation Script:

    • Open PowerShell as Administrator.

    • Navigate to the project's root directory (cd C:\Servers\SuperWinCLIServer).

    • Execute the installation script: .\install-service.ps1

    • This script uses NSSM to install and configure the MCPServer service to run node.exe dist/index.js as LocalSystem, starting automatically.

  6. Verify Service Status:

    • In the same administrative PowerShell window, run: Get-Service MCPServer

    • The status should be Running. If it's Stopped, check the NSSM logs or Windows Event Viewer (Application and System logs) for errors.

Configuration (config.json) Details

  • security:

    • maxCommandLength: Max characters allowed in a command string.

    • blockedCommands: Array of command names (without extension) to block (case-insensitive).

    • blockedArguments: Array of exact arguments to block (case-insensitive).

    • allowedPaths: Crucial setting. Array of absolute paths. If restrictWorkingDirectory is true, commands can only be executed if their working directory starts with one of these paths. Paths are compared case-insensitively after normalization. Use double backslashes (e.g., "C:\\Tools\\Scripts").

    • restrictWorkingDirectory: Boolean. If true, enforce the allowedPaths check for the working directory. Highly recommended to keep true.

    • logCommands: Boolean. If true, executed commands and their output (truncated) are stored in memory (up to maxHistorySize).

    • maxHistorySize: Max number of commands to keep in the in-memory history.

    • commandTimeout: Seconds before a running command is killed automatically.

    • enableInjectionProtection: Boolean. If true, attempts to block shell operators (&, |, ;, etc. defined per shell) in commands.

  • shells: Configure available local shells (powershell, cmd, gitbash).

    • enabled: Boolean. Allow use of this shell.

    • command: Path to the shell executable.

    • args: Array of default arguments passed to the shell before the user's command.

    • blockedOperators: Array of strings/characters to block within commands for this specific shell (used if enableInjectionProtection is true).

  • ssh: Configure remote command execution via SSH.

    • enabled: Boolean. Enable the ssh_execute and ssh_disconnect tools.

    • connections: Object containing named connection configurations (host, port, username, password/privateKeyPath).

  • Configuration Merging: When config.json is loaded, if it contains a security or shells section, that entire section replaces the default configuration for that section. It does not merge individual fields within security or shells. The ssh section is merged more granularly. Ensure your config.json includes all necessary fields for these sections if you customize them.

Service Management (NSSM)

Once installed via install-service.ps1, you can manage the service using standard Windows tools or NSSM commands from an administrative PowerShell/CMD in the project directory:

  • Start: Start-Service MCPServer or .\nssm.exe start MCPServer

  • Stop: Stop-Service MCPServer or .\nssm.exe stop MCPServer

  • Restart: Restart-Service MCPServer or .\nssm.exe restart MCPServer

  • Status: Get-Service MCPServer or .\nssm.exe status MCPServer

  • Edit Configuration (Advanced): .\nssm.exe edit MCPServer (Opens the NSSM GUI editor)

  • View Configuration: .\nssm.exe dump MCPServer

Uninstallation (NSSM)

  1. Open PowerShell as Administrator.

  2. Navigate to the project's root directory.

  3. Execute the uninstallation script: .\uninstall-service.ps1

  4. This uses NSSM to stop and remove the MCPServer service.

Alternative Execution (Manual/Debug)

You can run the server directly without installing it as a service for testing or debugging purposes:

  1. Ensure you have run npm install.

  2. Ensure config.json exists and is configured.

  3. Open a normal terminal (PowerShell/CMD) in the project root.

  4. Run: npm run start

  5. The server will run in the foreground. Press Ctrl + C to stop it.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

4 tools
execute_commandC

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
NameRequiredDescriptionDefault
commandYesCommand to execute
shellYesShell to use for command execution
workingDirNoWorking directory for command execution (optional)

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It describes what the tool does (executes commands) but lacks critical behavioral details: security implications, permission requirements, whether commands run synchronously/asynchronously, timeout behavior, error handling, or output format. For a command execution tool with zero annotation coverage, this is a significant gap in behavioral disclosure.

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

Conciseness3/5

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

The description is front-loaded with the core purpose, but the extensive examples (three full JSON blocks) dominate the text. While examples are helpful, they could be more concise or structured as a single example with variations. The description is appropriately sized but could be more efficiently organized.

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 command execution tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (stdout, stderr, exit codes), security considerations, or error conditions. Given the complexity and potential risks of command execution, more contextual information is needed for safe and effective use.

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?

Schema description coverage is 100%, providing good baseline documentation. The description adds value through concrete examples showing how parameters work together in different shells, illustrating shell-specific command syntax and working directory formats. This enhances understanding beyond the schema's technical definitions.

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's purpose: 'Execute a command in the specified shell (powershell, cmd, or gitbash)'. It provides a specific verb ('execute') and resource ('command'), but doesn't explicitly differentiate from sibling tools like 'ssh_execute' which likely executes commands over SSH. The purpose is clear but lacks sibling differentiation.

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?

The description provides no guidance on when to use this tool versus alternatives like 'ssh_execute' or 'get_command_history'. It shows example usage but doesn't specify contexts, prerequisites, or exclusions. Without any usage guidelines, the agent must infer when this tool is appropriate.

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

get_command_historyC

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
NameRequiredDescriptionDefault
limitNoMaximum number of history entries to return (default: 10, max: 1000)

TDQS

C2.9/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 behavioral disclosure. It implies a read-only operation but doesn't specify permissions, rate limits, or whether the history is filtered by session or user. The example response adds some context but lacks comprehensive behavioral traits.

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 appropriately sized and front-loaded with the core purpose, followed by helpful examples. However, the example usage and response could be integrated more seamlessly, and some sentences (like the standalone 'Example usage:') are slightly redundant.

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?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but has gaps. It covers the basic purpose and provides examples, but lacks usage guidelines and behavioral details, making it minimally viable for an agent to use correctly.

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 has 100% description coverage, so the schema already documents the 'limit' parameter thoroughly. The description doesn't add any semantic details beyond what the schema provides, such as explaining how ordering works or what 'history' encompasses, resulting in a baseline score.

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's purpose with a specific verb ('Get') and resource ('history of executed commands'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'execute_command' or 'ssh_execute', which prevents a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives like 'execute_command' or 'ssh_execute', nor does it mention any prerequisites or exclusions. The example usage is helpful but doesn't constitute usage guidelines.

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
NameRequiredDescriptionDefault
connectionIdYesID of the SSH connection to disconnect

TDQS

A3.7/5.0
Behavior3/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 behavioral disclosure. It mentions 'cleanly close SSH connections', which implies a graceful termination rather than abrupt disconnection, adding useful context. However, it doesn't cover important behavioral aspects like whether this requires specific permissions, what happens to ongoing operations, or error handling for invalid connection IDs.

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 extremely concise and well-structured. It starts with the core purpose, provides a clear usage example, and ends with practical guidance. Every sentence earns its place, with no wasted words or redundant information.

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?

For a simple disconnect tool with one parameter and no output schema, the description is reasonably complete. It covers the basic purpose, usage context, and provides an example. However, given the lack of annotations and output schema, it could benefit from more behavioral details about what 'cleanly close' entails or what happens after disconnection.

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 schema description coverage is 100%, with the parameter 'connectionId' fully documented in the schema as 'ID of the SSH connection to disconnect'. The description doesn't add any additional parameter information beyond what's in the schema, but since schema coverage is complete, the baseline score of 3 is appropriate.

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 action ('Disconnect from') and target ('SSH server'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'ssh_execute', but the verb 'disconnect' is specific enough to distinguish it from execution or query tools.

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 clear context for when to use this tool: 'when they're no longer needed' and 'to cleanly close SSH connections'. This gives practical guidance on timing and purpose. However, it doesn't explicitly mention alternatives or when NOT to use it, such as distinguishing it from simply letting connections time out.

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
NameRequiredDescriptionDefault
commandYesCommand to execute
connectionIdYesID of the SSH connection to use

TDQS

A3.6/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 discloses that SSH configuration is required and provides an example, but lacks details on behavioral traits such as error handling, timeouts, security implications, or output format. The description adds some context (configuration needs) but is incomplete for a mutation tool with no annotation coverage.

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 appropriately sized and front-loaded with the core purpose in the first sentence. The example and configuration details are relevant but could be more concise. Overall, it's efficient with minimal waste, though the configuration block is lengthy.

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?

Given the tool's complexity (remote execution with configuration dependencies), lack of annotations, and no output schema, the description is partially complete. It covers the basic purpose and configuration but misses critical details like return values, error behavior, and security considerations. It's adequate but has clear gaps for a mutation tool.

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 description coverage is 100%, with clear parameter descriptions in the schema. The description adds minimal value beyond the schema by illustrating usage in an example, but does not provide additional semantics like command syntax constraints or connectionId enumeration details. Baseline 3 is appropriate as 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 clearly states the specific action ('Execute a command') and resource ('on a remote host via SSH'), distinguishing it from sibling tools like 'execute_command' (likely local), 'get_command_history' (querying), and 'ssh_disconnect' (connection management). The verb+resource combination is precise and unambiguous.

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 implies usage context through the example and configuration details, suggesting this tool is for remote SSH execution. However, it lacks explicit guidance on when to use this versus alternatives like 'execute_command' (e.g., for local vs. remote commands) or prerequisites beyond configuration. No explicit when-not-to-use or alternative recommendations are provided.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observedexecute_command
    • First observedget_command_history
    • First observedssh_disconnect
    • First observedssh_execute
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Windows CLI MCP Server

    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.
    9
    1,215
    269
    MIT

  • Windows CLI MCP Server

    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.
    6
    36
    4
    MIT

  • Windows CLI MCP Server

    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.
    34
    2
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Faucet94/super-win-cli-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server