The cli-mcp-server provides secure execution of whitelisted command-line operations within a restricted environment.
Execute CLI commands: Run whitelisted commands (pwd, cat, echo, find, ls, grep) with allowed flags (-l, -h, --help, -v, -a, -r) within the restricted /app directory.
View security rules: Check the current security configuration, including allowed commands, flags, and operational restrictions.
Secure execution: Enforces strict validation of commands and flags while preventing shell operators (e.g., &&, |, >) by default.
Controlled environment: All operations are constrained within the /app directory, preventing unauthorized access.
Allows execution of whitelisted shell commands with comprehensive security features including command and flag whitelisting, path validation, and protection against injection attacks.
Click on "Install 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., "@cli-mcp-server show me what files are in the current directory"
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.
A secure Model Context Protocol (MCP) server implementation for executing controlled command-line operations with comprehensive security features.
This MCP server enables secure command-line execution with robust security measures including command whitelisting, path validation, and execution controls. Perfect for providing controlled CLI access to LLM applications while maintaining security.
Related MCP server: Windows CLI MCP Server
🔒 Secure command execution with strict validation
⚙️ Configurable command and flag whitelisting with 'all' option
🛡️ Path traversal prevention and validation
🚫 Shell operator injection protection
⏱️ Execution timeouts and length limits
📝 Detailed error reporting
🔄 Async operation support
🎯 Working directory restriction and validation
Configure the server using environment variables:
Variable | Description | Default |
| Base directory for command execution (Required) | None (Required) |
| Comma-separated list of allowed commands or 'all' |
|
| Comma-separated list of allowed flags or 'all' |
|
| Maximum command string length |
|
| Command execution timeout (seconds) |
|
| Allow shell operators (&&, ||, |, >, etc.) |
|
Note: Setting ALLOWED_COMMANDS or ALLOWED_FLAGS to 'all' will allow any command or flag respectively.
To install CLI MCP Server for Claude Desktop automatically via Smithery:
npx @smithery/cli install cli-mcp-server --client claudeExecutes whitelisted CLI commands within allowed directories.
Input Schema:
{
"command": {
"type": "string",
"description": "Single command to execute (e.g., 'ls -l' or 'cat file.txt')"
}
}Security Notes:
Shell operators (&&, |, >, >>) are not supported by default, but can be enabled with ALLOW_SHELL_OPERATORS=true
Commands must be whitelisted unless ALLOWED_COMMANDS='all'
Flags must be whitelisted unless ALLOWED_FLAGS='all'
All paths are validated to be within ALLOWED_DIR
Displays current security configuration and restrictions, including:
Working directory
Allowed commands
Allowed flags
Security limits (max command length and timeout)
Add to your ~/Library/Application\ Support/Claude/claude_desktop_config.json:
Development/Unpublished Servers Configuration
{
"mcpServers": {
"cli-mcp-server": {
"command": "uv",
"args": [
"--directory",
"<path/to/the/repo>/cli-mcp-server",
"run",
"cli-mcp-server"
],
"env": {
"ALLOWED_DIR": "</your/desired/dir>",
"ALLOWED_COMMANDS": "ls,cat,pwd,echo",
"ALLOWED_FLAGS": "-l,-a,--help,--version",
"MAX_COMMAND_LENGTH": "1024",
"COMMAND_TIMEOUT": "30",
"ALLOW_SHELL_OPERATORS": "false"
}
}
}
}Published Servers Configuration
{
"mcpServers": {
"cli-mcp-server": {
"command": "uvx",
"args": [
"cli-mcp-server"
],
"env": {
"ALLOWED_DIR": "</your/desired/dir>",
"ALLOWED_COMMANDS": "ls,cat,pwd,echo",
"ALLOWED_FLAGS": "-l,-a,--help,--version",
"MAX_COMMAND_LENGTH": "1024",
"COMMAND_TIMEOUT": "30",
"ALLOW_SHELL_OPERATORS": "false"
}
}
}
}In case it's not working or showing in the UI, clear your cache via
uv clean.
✅ Command whitelist enforcement with 'all' option
✅ Flag validation with 'all' option
✅ Path traversal prevention and normalization
✅ Shell operator blocking (with opt-in support via ALLOW_SHELL_OPERATORS=true)
✅ Command length limits
✅ Execution timeouts
✅ Working directory restrictions
✅ Symlink resolution and validation
The server provides detailed error messages for:
Security violations (CommandSecurityError)
Command timeouts (CommandTimeoutError)
Invalid command formats
Path security violations
Execution failures (CommandExecutionError)
General command errors (CommandError)
Python 3.10+
MCP protocol library
To prepare the package for distribution:
Sync dependencies and update lockfile:
uv syncBuild package distributions:
uv buildThis will create source and wheel distributions in the
dist/directory.
Publish to PyPI:
uv publish --token {{YOUR_PYPI_API_TOKEN}}Since MCP servers run over stdio, debugging can be challenging. For the best debugging experience, we strongly recommend using the MCP Inspector.
You can launch the MCP Inspector via npm with
this command:
npx @modelcontextprotocol/inspector uv --directory {{your source code local directory}}/cli-mcp-server run cli-mcp-serverUpon launching, the Inspector will display a URL that you can access in your browser to begin debugging.
This project is licensed under the MIT License - see the LICENSE file for details.
For more information or support, please open an issue on the project repository.
Allows command (CLI) execution in the directory: /app
Available commands: pwd, ls, cat Available flags: -l, --help, -a
Shell operators (&&, ||, |, >, >>, <, <<, ;) are not supported. Set ALLOW_SHELL_OPERATORS=true to enable.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Single command to execute (example: 'ls -l' or 'cat file.txt') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: execution directory constraint (/app), available commands (pwd, ls, cat), available flags (-l, --help, -a), shell operator restrictions, and how to enable operators. It doesn't mention security implications, permission requirements, or output format details.
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?
Four sentences with zero waste - each provides essential information: purpose, available commands/flags, restrictions, and how to lift restrictions. The structure is front-loaded with the core purpose first, followed by operational details.
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 single-parameter command execution tool with no annotations and no output schema, the description provides substantial context: execution environment, command/flag constraints, and operator restrictions. It doesn't describe return values or error behavior, but given the tool's relative simplicity, this is reasonably complete.
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 100% with the parameter 'command' well-documented in the schema. The description adds context about what constitutes valid commands (specific examples and restrictions), but doesn't provide additional parameter-specific semantics beyond what the schema already covers. Baseline 3 is appropriate when schema does heavy lifting.
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 explicitly states 'Allows command (CLI) execution in the directory: /app' - a specific verb ('execute') with clear resource ('command/CLI') and location constraint ('/app'). It distinguishes from the only sibling tool 'show_security_rules' which appears unrelated to command execution.
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 clear context about what commands and flags are available, and when shell operators are/aren't supported. However, it doesn't explicitly state when to use this tool versus alternatives (though the sibling tool appears unrelated) or provide exclusion guidance beyond the shell operator limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show what commands and operations are allowed in this environment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('show'), but doesn't specify if it requires authentication, returns structured data, has rate limits, or details output format. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
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 a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.
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?
Given the complexity of security rules and lack of annotations or output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list, structured data), how to interpret 'allowed,' or any prerequisites. This leaves the agent with insufficient context for effective use.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, which is appropriate here, but it could hint at implicit context like environment scope. Baseline is 4 for zero parameters, as no compensation is needed.
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's purpose: 'Show what commands and operations are allowed in this environment.' It specifies the verb 'show' and the resource 'commands and operations' with their context 'in this environment.' However, it doesn't explicitly differentiate from its sibling 'run_command,' which likely executes commands rather than showing allowed ones.
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 no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'run_command' or any context for usage, such as checking permissions before execution or troubleshooting. This leaves the agent without explicit direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have completely distinct purposes: run_command executes CLI commands with specific constraints, while show_security_rules displays allowed operations and permissions. There is no overlap or ambiguity between these functions.
Both tools follow a clear verb_noun pattern (run_command, show_security_rules), which is consistent and readable. The minor deviation is that 'run' and 'show' are different verbs, but this is appropriate given their distinct actions.
With only 2 tools, the server feels thin for a CLI server that presumably handles command execution and environment management. A typical CLI server would benefit from more tools (e.g., for file operations, process management, or configuration), making this count insufficient for the apparent scope.
The tool surface is severely incomplete for a CLI server. It lacks basic operations like file creation, deletion, editing, process monitoring, or environment configuration. The run_command tool is limited to a few commands, and there are no tools for managing the CLI environment beyond showing security rules, creating significant gaps for agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MladenSU/cli-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
