Skip to main content
Glama
enesjakozh
cfdude

Super Shell MCP Server

by cfdude
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Super Shell MCP Server

An MCP (Model Context Protocol) server for executing shell commands across multiple platforms (Windows, macOS, Linux). This server provides a secure way to execute shell commands with built-in whitelisting and approval mechanisms.

🎉 Now available as a Claude Desktop Extension! Install with one click using the .dxt package - no developer tools or configuration required.

Features

  • Execute shell commands through MCP on Windows, macOS, and Linux

  • Automatic platform detection and shell selection

  • Support for multiple shells:

    • Windows: cmd.exe, PowerShell

    • macOS: zsh, bash, sh

    • Linux: bash, sh, zsh

  • Shell parsing disabled by default to eliminate command-injection risk, with an explicit opt-in mode for trusted workflows

  • Command whitelisting with security levels:

    • Safe: Commands that can be executed without approval

    • Requires Approval: Commands that need explicit approval before execution

    • Forbidden: Commands that are explicitly blocked

  • Platform-specific command whitelists

  • Non-blocking approval workflow for potentially dangerous commands

  • Comprehensive logging system with file-based logs

  • Comprehensive command management tools

  • Platform information tool for diagnostics

Related MCP server: Mac Shell MCP Server

Installation

Option 1: Claude Desktop Extension (.dxt) - Recommended

One-Click Installation for Claude Desktop:

  1. Download the super-shell-mcp.dxt file from the latest release

  2. Quick Install: Double-click the .dxt file while Claude Desktop is open

    OR

    Manual Install:

    • Open Claude Desktop

    • Go to Settings > Extensions

    • Click "Add Extension"

    • Select the downloaded super-shell-mcp.dxt file

  3. Configure (optional): Set custom shell path if needed

  4. Start using - The extension is ready to use immediately!

✅ Benefits of DXT Installation:

  • No developer tools required (Node.js, Python, etc.)

  • No manual configuration files

  • Automatic dependency management

  • One-click installation and updates

  • Secure credential storage in OS keychain

Option 2: Installing via Smithery

To install Super Shell MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @cfdude/super-shell-mcp --client claude

Option 3: Installing Manually

# Clone the repository
git clone https://github.com/cfdude/super-shell-mcp.git
cd super-shell-mcp

# Install dependencies
npm install

# Build the project
npm run build

Usage

For Claude Desktop Extension Users (.dxt)

If you installed using the .dxt extension (Option 1), you're ready to go! No additional configuration needed. The extension handles everything automatically:

  • ✅ Automatic startup when Claude Desktop launches

  • ✅ Platform detection and appropriate shell selection

  • ✅ Built-in security with command whitelisting and approval workflows

  • ✅ Optional configuration via Claude Desktop's extension settings

For Manual Installation Users

If you installed manually (Option 2 or 3), you'll need to configure Claude Desktop or your MCP client:

Starting the Server Manually

npm start

Or directly:

node build/index.js

Manual Configuration for MCP Clients

For manual installations, both Roo Code and Claude Desktop use a similar configuration format for MCP servers:

Using NPX (Recommended for Manual Setup)

The easiest way to use Super Shell MCP is with NPX, which automatically installs and runs the package from npm without requiring manual setup. The package is available on NPM at https://www.npmjs.com/package/super-shell-mcp.

Roo Code Configuration with NPX
"super-shell": {
  "command": "npx",
  "args": [
    "-y",
    "super-shell-mcp"
  ],
  "alwaysAllow": [],
  "disabled": false
}
Claude Desktop Configuration with NPX
"super-shell": {
  "command": "npx",
  "args": [
    "-y",
    "super-shell-mcp"
  ],
  "alwaysAllow": false,
  "disabled": false
}

Option 2: Using Local Installation

If you prefer to use a local installation, add the following to your Roo Code MCP settings configuration file (located at ~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json):

"super-shell": {
  "command": "node",
  "args": [
    "/path/to/super-shell-mcp/build/index.js"
  ],
  "alwaysAllow": [],
  "disabled": false
}

You can optionally provide a trusted shell and opt into shell parsing by setting environment variables instead of command-line flags:

"super-shell": {
  "command": "node",
  "args": [
    "/path/to/super-shell-mcp/build/index.js"
  ],
  "env": {
    "CUSTOM_SHELL": "/usr/bin/bash",
    "SUPER_SHELL_USE_SHELL": "true"
  },
  "alwaysAllow": [],
  "disabled": false
}

Windows 11 example:

"super-shell": {
  "command": "C:\\Program Files\\nodejs\\node.exe",
  "args": [
    "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npx-cli.js",
    "-y",
    "super-shell-mcp",
    "C:\\Users\\username"
  ],
  "env": {
    "CUSTOM_SHELL": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
    "SUPER_SHELL_USE_SHELL": "true"
  },
  "alwaysAllow": [],
  "disabled": false
}

Claude Desktop Configuration

Add the following to your Claude Desktop configuration file (located at ~/Library/Application Support/Claude/claude_desktop_config.json):

"super-shell": {
  "command": "node",
  "args": [
    "/path/to/super-shell-mcp/build/index.js"
  ],
  "alwaysAllow": false,
  "disabled": false
}

For Windows users, the configuration file is typically located at %APPDATA%\Claude\claude_desktop_config.json.

Platform-Specific Configuration

Windows

  • Default shell: cmd.exe (or PowerShell if available)

  • Configuration paths:

    • Roo Code: %APPDATA%\Code\User\globalStorage\rooveterinaryinc.roo-cline\settings\cline_mcp_settings.json

    • Claude Desktop: %APPDATA%\Claude\claude_desktop_config.json

  • Shell path examples:

    • cmd.exe: C:\\Windows\\System32\\cmd.exe

    • PowerShell: C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe

    • PowerShell Core: C:\\Program Files\\PowerShell\\7\\pwsh.exe

macOS

  • Default shell: /bin/zsh

  • Configuration paths:

    • Roo Code: ~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

    • Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Shell path examples:

    • zsh: /bin/zsh

    • bash: /bin/bash

    • sh: /bin/sh

Linux

  • Default shell: /bin/bash (or $SHELL environment variable)

  • Configuration paths:

    • Roo Code: ~/.config/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

    • Claude Desktop: ~/.config/Claude/claude_desktop_config.json

  • Shell path examples:

    • bash: /bin/bash

    • sh: /bin/sh

    • zsh: /usr/bin/zsh

Shell Execution Modes & Environment Variables

Shell parsing is disabled by default for security. Customise behaviour with the following environment variables:

  • SUPER_SHELL_USE_SHELL: set to true (or 1/yes/on) to enable shell parsing for trusted workflows. Omit or set to false to keep the safer default.

  • CUSTOM_SHELL: optional path to the shell executable used when shell parsing is enabled.

  • SUPER_SHELL_COMMAND_TIMEOUT: optional override (milliseconds) for the default 30s command timeout.

⚠️ Enabling shell parsing reintroduces the risk of command injection. Only enable it when you fully trust the command source and payload.

Replace /path/to/super-shell-mcp with the actual path where you cloned the repository.

Note:

  • For Roo Code: Setting alwaysAllow to an empty array [] is recommended for security reasons, as it will prompt for approval before executing any commands. If you want to allow specific commands without prompting, you can add their names to the array, for example: "alwaysAllow": ["execute_command", "get_whitelist"].

  • For Claude Desktop: Setting alwaysAllow to false is recommended for security reasons. Claude Desktop uses a boolean value instead of an array, where false means all commands require approval and true means all commands are allowed without prompting.

Important: The alwaysAllow parameter is processed by the MCP client (Roo Code or Claude Desktop), not by the Super Shell MCP server itself. The server will work correctly with either format, as the client handles the approval process before sending requests to the server.

Available Tools

The server exposes the following MCP tools:

get_platform_info

Get information about the current platform and shell.

{}

execute_command

Execute a shell command on the current platform.

{
  "command": "ls",
  "args": ["-la"]
}

get_whitelist

Get the list of whitelisted commands.

{}

add_to_whitelist

Add a command to the whitelist.

{
  "command": "python3",
  "securityLevel": "safe",
  "description": "Run Python 3 scripts"
}

update_security_level

Update the security level of a whitelisted command.

{
  "command": "python3",
  "securityLevel": "requires_approval"
}

remove_from_whitelist

Remove a command from the whitelist.

{
  "command": "python3"
}

get_pending_commands

Get the list of commands pending approval.

{}

approve_command

Approve a pending command.

{
  "commandId": "command-uuid-here"
}

deny_command

Deny a pending command.

{
  "commandId": "command-uuid-here",
  "reason": "This command is potentially dangerous"
}

Default Whitelisted Commands

The server includes platform-specific command whitelists that are automatically selected based on the detected platform.

Common Safe Commands (All Platforms)

  • echo - Print text to standard output

Unix-like Safe Commands (macOS/Linux)

  • ls - List directory contents

  • pwd - Print working directory

  • echo - Print text to standard output

  • cat - Concatenate and print files

  • grep - Search for patterns in files

  • find - Find files in a directory hierarchy

  • cd - Change directory

  • head - Output the first part of files

  • tail - Output the last part of files

  • wc - Print newline, word, and byte counts

Windows-specific Safe Commands

  • dir - List directory contents

  • type - Display the contents of a text file

  • findstr - Search for strings in files

  • where - Locate programs

  • whoami - Display current user

  • hostname - Display computer name

  • ver - Display operating system version

Commands Requiring Approval

Windows Commands Requiring Approval

  • copy - Copy files

  • move - Move files

  • mkdir - Create directories

  • rmdir - Remove directories

  • rename - Rename files

  • attrib - Change file attributes

Unix Commands Requiring Approval

  • mv - Move (rename) files

  • cp - Copy files and directories

  • mkdir - Create directories

  • touch - Change file timestamps or create empty files

  • chmod - Change file mode bits

  • chown - Change file owner and group

Forbidden Commands

Windows Forbidden Commands

  • del - Delete files

  • erase - Delete files

  • format - Format a disk

  • runas - Execute a program as another user

Unix Forbidden Commands

  • rm - Remove files or directories

  • sudo - Execute a command as another user

Security Considerations

  • All commands are executed with the permissions of the user running the MCP server

  • Commands requiring approval are held in a queue until explicitly approved

  • Forbidden commands are never executed

  • The server uses Node.js's execFile instead of exec to prevent shell injection

  • Arguments are validated against allowed patterns when specified

Extending the Whitelist

You can extend the whitelist by using the add_to_whitelist tool. For example:

{
  "command": "npm",
  "securityLevel": "requires_approval",
  "description": "Node.js package manager"
}

NPM Package Information

Super Shell MCP is available as an npm package at https://www.npmjs.com/package/super-shell-mcp.

Benefits of Using NPX

Using the NPX method (as shown in Option 1 of the Configuration section) offers several advantages:

  1. No Manual Setup: No need to clone the repository, install dependencies, or build the project

  2. Automatic Updates: Always uses the latest published version

  3. Cross-Platform Compatibility: Works the same way on Windows, macOS, and Linux

  4. Simplified Configuration: Shorter configuration with no absolute paths

  5. Reduced Maintenance: No local files to manage or update

Using from GitHub

If you prefer to use the latest development version directly from GitHub:

"super-shell": {
  "command": "npx",
  "args": [
    "-y",
    "github:cfdude/super-shell-mcp"
  ],
  "alwaysAllow": [],  // For Roo Code
  "disabled": false
}

Publishing Your Own Version

If you want to publish your own modified version to npm:

  1. Update the package.json with your details

  2. Ensure the "bin" field is properly configured:

    "bin": {
  "super-shell-mcp": "./build/index.js"
}

  3. Publish to npm:

    npm publish

NPX Best Practices

For optimal integration with MCP clients using NPX, this project follows these best practices:

  1. Executable Entry Point: The main file includes a shebang line (#!/usr/bin/env node) and is made executable during build.

  2. Package Configuration:

    • "type": "module" - Ensures ES Modules are used

    • "bin" field - Maps the command name to the entry point

    • "files" field - Specifies which files to include when publishing

    • "prepare" script - Ensures compilation happens on install

  3. TypeScript Configuration:

    • "module": "NodeNext" - Proper ES Modules support

    • "moduleResolution": "NodeNext" - Consistent with ES Modules

  4. Automatic Installation and Execution:

    • The MCP client configuration uses npx -y to automatically install and run the package

    • No terminal window is tied up as the process runs in the background

  5. Publishing Process:

    # Update version in package.json
npm version patch  # or minor/major as appropriate

# Build and publish
npm publish

These practices ensure the MCP server can be started automatically by the MCP client without requiring a separate terminal window, improving user experience and operational efficiency.

Troubleshooting

Cross-Platform Issues

Windows-Specific Issues

  1. PowerShell Script Execution Policy

    • Issue: PowerShell may block script execution with the error "Execution of scripts is disabled on this system"

    • Solution: Run PowerShell as Administrator and execute Set-ExecutionPolicy RemoteSigned or use the -ExecutionPolicy Bypass parameter when configuring the shell

  2. Path Separators

    • Issue: Windows uses backslashes (\) in paths, which need to be escaped in JSON

    • Solution: Use double backslashes (\\) in JSON configuration files, e.g., C:\\Windows\\System32\\cmd.exe

  3. Command Not Found

    • Issue: Windows doesn't have Unix commands like ls, grep, etc.

    • Solution: Use Windows equivalents (dir instead of ls, findstr instead of grep)

macOS/Linux-Specific Issues

  1. Shell Permissions

    • Issue: Permission denied when executing commands

    • Solution: Ensure the shell has appropriate permissions with chmod +x /path/to/shell

  2. Environment Variables

    • Issue: Environment variables not available in MCP server

    • Solution: Set environment variables in the shell's profile file (.zshrc, .bashrc, etc.)

General Troubleshooting

  1. Shell Detection Issues

    • Issue: Server fails to detect the correct shell

    • Solution: Explicitly specify the shell path in the configuration

  2. Command Execution Timeout

    • Issue: Commands taking too long and timing out

    • Solution: Increase the timeout value in the command service constructor

Logging System

The server includes a comprehensive logging system that writes logs to a file for easier debugging and monitoring:

  1. Log File Location

    • Default: logs/super-shell-mcp.log in the server's directory

    • The logs directory is created automatically and tracked by Git (with a .gitkeep file)

    • Log files themselves are excluded from Git via .gitignore

    • Contains detailed information about server operations, command execution, and approval workflow

  2. Log Levels

    • INFO: General operational information

    • DEBUG: Detailed debugging information

    • ERROR: Error conditions and exceptions

  3. Viewing Logs

    • Use standard file viewing commands to check logs:

      # View the entire log
cat logs/super-shell-mcp.log

# Follow log updates in real-time
tail -f logs/super-shell-mcp.log

  4. Log Content

    • Server startup and configuration

    • Command execution requests and results

    • Approval workflow events (pending, approved, denied)

    • Error conditions and troubleshooting information

  5. Whitelist Management

    • Issue: Need to add custom commands to whitelist

    • Solution: Use the add_to_whitelist tool to add commands specific to your environment

Known Issues

Android Studio Otter 2 Feature Drop Compatibility

Affected Version: Android Studio Otter 2 Feature Drop | 2025.2.2 Canary 3 (Build #AI-252.25557.131.2522.14357309)

Issue: Android Studio's MCP client implementation incorrectly serializes array parameters as strings when calling the execute_command tool. This causes commands with arguments to fail with the error:

Error: Expected array, received string

Example:

// This fails in Android Studio Otter 2
execute_command(
  command = "git",
  args = ["add", "."]  // Sent as string '["add", "."]' instead of array
)

Root Cause: This is a bug in Android Studio's MCP client, not in super-shell-mcp. The server correctly defines args as type array in its schema, and the issue has been verified to work correctly with:

  • Claude Desktop

  • Official MCP SDK clients

  • Other MCP-compatible tools

Status: This is an Android Studio bug. The super-shell-mcp server implements the MCP specification correctly.

Workaround: None currently available. Users experiencing this issue should report it to the Android Studio/JetBrains team.

References:

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

9 tools
add_to_whitelistC

Add a command to the whitelist

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesThe command to whitelist
securityLevelYesSecurity level for the command
descriptionNoDescription of the command

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 states the tool adds to a whitelist, implying a write operation, but doesn't cover critical aspects like permissions required, whether it overwrites existing entries, error conditions, or side effects. This leaves significant gaps for an agent to understand the tool's behavior.

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 a single, direct sentence that efficiently conveys the core action without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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?

Given the tool's complexity (a write operation with security implications), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what happens after adding (e.g., success response, error handling), how it integrates with the security system, or prerequisites, leaving the agent with incomplete context.

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, with clear documentation for all three parameters, including an enum for 'securityLevel'. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting.

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 ('Add') and resource ('command to the whitelist'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'update_security_level' or 'approve_command', which might have overlapping functionality in a security context.

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. For example, it doesn't clarify if this is for initial whitelisting versus updating existing entries, or how it relates to siblings like 'update_security_level' or 'remove_from_whitelist'.

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

approve_commandC

Approve a pending command

ParametersJSON Schema
NameRequiredDescriptionDefault
commandIdYesID of the command to approve

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 mutation ('Approve') but doesn't specify permissions required, whether the action is reversible, or what happens after approval (e.g., does it trigger execution?). This leaves critical behavioral traits unclear for a tool that likely changes system state.

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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral outcomes, error conditions, or integration with sibling tools (e.g., how approval relates to 'execute_command'), leaving gaps in understanding the tool's role in the broader context.

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 the single parameter 'commandId' well-documented in the schema. The description adds no additional meaning about the parameter beyond what the schema provides, such as format examples or sourcing guidance, so it meets the baseline for high schema coverage.

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 ('Approve') and the target resource ('a pending command'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'deny_command' beyond the opposite action, missing explicit differentiation that would warrant a score of 5.

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 'deny_command' or 'execute_command', nor does it mention prerequisites such as needing a pending command from 'get_pending_commands'. This lack of contextual direction leaves the agent without usage instructions.

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

deny_commandC

Deny a pending command

ParametersJSON Schema
NameRequiredDescriptionDefault
commandIdYesID of the command to deny
reasonNoReason for denial

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. 'Deny' implies a mutation that changes command status, but the description doesn't disclose behavioral traits like required permissions, whether denial is reversible, what happens to the denied command, or any side effects. This is a significant gap for a mutation tool with zero 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.

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place.

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?

Given the complexity of a command denial operation (a mutation with potential security implications), no annotations, no output schema, and sibling tools like 'approve_command', the description is incomplete. It lacks context on prerequisites, consequences, alternatives, or return values, leaving significant gaps for an AI agent to use it 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?

Schema description coverage is 100%, so the schema already documents both parameters (commandId and reason) adequately. The description doesn't add any meaning beyond what the schema provides, such as explaining what constitutes a valid reason or how the commandId is obtained. Baseline 3 is appropriate when schema does the heavy lifting.

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 'Deny a pending command' clearly states the action (deny) and target resource (pending command). It's specific and unambiguous, though it doesn't explicitly differentiate from sibling tools like 'approve_command' or 'execute_command' beyond the verb choice.

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. It doesn't mention prerequisites (e.g., needing a pending command ID), when denial is appropriate, or how it differs from 'approve_command' or other command-handling tools in the sibling list.

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

execute_commandC

Execute a shell command on the current platform

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesThe command to execute
argsNoCommand arguments

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 states the action but lacks critical details such as security implications, permission requirements, whether it's destructive, rate limits, or output format. This is a significant gap for a tool that executes shell commands, which can have high-risk behaviors.

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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, making it easy to parse quickly.

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?

Given the complexity of executing shell commands (potentially high-risk with no annotations) and lack of output schema, the description is incomplete. It fails to address security, permissions, or return values, leaving the agent with insufficient context for safe and effective use.

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, with clear documentation for 'command' and 'args'. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage without extra value.

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 ('Execute') and resource ('a shell command on the current platform'), making the purpose understandable. However, it doesn't distinguish this tool from its siblings like 'approve_command' or 'deny_command', which appear to be related to command management but have different functions.

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. Given siblings like 'approve_command' and 'deny_command', it's unclear if 'execute_command' requires approval, operates independently, or has specific prerequisites, leaving the agent without usage context.

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

get_pending_commandsB

Get the list of commands pending approval

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves pending commands but doesn't mention whether this requires special permissions, how results are formatted, if there are rate limits, or what happens if no commands are pending. For a security/approval-related tool, this is a significant gap.

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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential 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 zero-parameter tool with no output schema, the description provides the minimum viable information about what it does. However, given the security/approval context and sibling tools that suggest this is part of a command management system, more information about permissions, return format, or typical usage patterns would be helpful.

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 tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, which is correct. Baseline for zero parameters is 4.

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 ('Get') and resource ('list of commands pending approval'), making the purpose immediately understandable. It doesn't specifically differentiate from siblings like 'execute_command' or 'approve_command', but the verb+resource combination is unambiguous in context.

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 provided about when to use this tool versus alternatives like 'execute_command' or 'approve_command'. The description only states what it does, not when it should be used in relation to the sibling tools that manage command approval workflows.

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

get_platform_infoB

Get information about the current platform and shell

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/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 the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify what information is returned (e.g., OS version, shell type, environment details), whether it requires permissions, or if there are rate limits. This leaves significant gaps for a tool with zero 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.

Conciseness5/5

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 unnecessary words. It is front-loaded with the core action ('Get information'), making it easy to parse, and every part of the sentence contributes to understanding the tool's function.

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?

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves system information. It doesn't explain what specific data is returned (e.g., platform details, shell version) or the format of the output, which is critical for an agent to use the tool effectively. This leaves too much ambiguity for practical 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?

The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied as per the rules for tools with no parameters.

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 ('information about the current platform and shell'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings (like 'execute_command' or 'get_pending_commands'), which focus on command execution and management rather than platform metadata.

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. It doesn't mention prerequisites, context (e.g., use for system diagnostics or compatibility checks), or exclusions, leaving the agent to infer usage based on the name alone.

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

get_whitelistB

Get the list of whitelisted commands

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, or what format the returned list has. This is inadequate for a tool with zero 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.

Conciseness5/5

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 with no wasted words. It's perfectly front-loaded and appropriately sized for a simple retrieval tool.

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?

Given no annotations and no output schema, the description is incomplete for a tool that likely returns structured data. It doesn't explain what 'whitelisted commands' entails, the return format, or any behavioral context, leaving significant gaps for an agent to use it correctly.

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 tool has zero parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate here, warranting a baseline score above minimum viable.

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 verb ('Get') and resource ('list of whitelisted commands'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_pending_commands' or 'get_platform_info' beyond the resource name, 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 'get_pending_commands' or 'add_to_whitelist'. There's no mention of prerequisites, context, or exclusions, leaving usage entirely implicit from the tool name alone.

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

remove_from_whitelistC

Remove a command from the whitelist

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesThe command to remove from whitelist

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 states the tool removes a command from a whitelist, implying a mutation operation, but doesn't describe side effects (e.g., whether this affects pending commands or security levels), permissions required, or error conditions. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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 a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.

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?

Given the tool's mutation nature (removing from a whitelist), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what happens after removal, error handling, or integration with sibling tools (e.g., 'get_whitelist'), leaving the agent with insufficient context for safe and effective use.

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, with the single parameter 'command' documented as 'The command to remove from whitelist'. The description doesn't add any meaning beyond this, such as format examples or constraints, but the schema provides adequate baseline information, justifying a score of 3.

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 ('remove') and target resource ('a command from the whitelist'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'deny_command' or 'update_security_level', which might have overlapping security functions, but the verb+resource combination is specific enough for basic understanding.

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 'deny_command' or 'update_security_level', nor does it mention prerequisites (e.g., whether the command must already be in the whitelist). It simply states what the tool does without contextual usage information.

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

update_security_levelC

Update the security level of a whitelisted command

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesThe command to update
securityLevelYesNew security level for the command

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 states this is an update operation but doesn't clarify whether this requires admin permissions, if changes are reversible, what happens to existing security settings, or potential side effects. For a security-related mutation tool, this lack of transparency is a significant gap.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, 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.

Completeness2/5

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

Given the complexity of a security-level update tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or return values, nor does it help differentiate from sibling tools. The agent would lack sufficient context to use this tool effectively.

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 both parameters clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides (e.g., it doesn't explain what 'whitelisted command' means or provide examples). The baseline score of 3 reflects adequate but unenhanced parameter documentation.

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 ('Update') and the target resource ('security level of a whitelisted command'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'approve_command' or 'deny_command', which might have overlapping functionality in a security context.

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 'add_to_whitelist' or 'remove_from_whitelist'. It doesn't mention prerequisites (e.g., whether the command must already be whitelisted) or contextual constraints, leaving the agent with insufficient usage direction.

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. 9 tool updates
    • First observedadd_to_whitelist
    • First observedapprove_command
    • First observeddeny_command
    • First observedexecute_command
    • First observedget_pending_commands
    • First observedget_platform_info
    • First observedget_whitelist
    • First observedremove_from_whitelist
    • First observedupdate_security_level
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity. For example, add_to_whitelist and remove_from_whitelist handle whitelist modifications, while approve_command and deny_command manage pending commands, and execute_command performs command execution. The descriptions reinforce these distinct roles, making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as add_to_whitelist, get_pending_commands, and update_security_level. This predictability aids agent understanding and navigation without any deviations or mixed conventions.

Tool Count5/5

With 9 tools, the count is well-scoped for a shell security management server. Each tool serves a clear purpose in the workflow, from command execution and approval to whitelist and platform management, avoiding bloat or thin coverage.

Completeness5/5

The tool set provides complete coverage for shell command security management, including CRUD operations for the whitelist (add, get, remove, update), a full lifecycle for pending commands (get, approve, deny), and core utilities like execute_command and get_platform_info. No obvious gaps exist for the domain.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

  • MCP Shell Server

    mako10k
    A
    license
    B
    quality
    A
    maintenance
    A secure MCP server for shell operations, terminal management, and process control, enabling AI assistants to safely execute commands and manage interactive sessions.
    13
    204
    6
    MIT

  • dynamic-shell-server

    codelion
    A
    license
    Not graded
    quality
    F
    maintenance
    A Model Context Protocol (MCP) server that enables secure execution of shell commands with a dynamic approval system, audit logging, and command revocation.
    41
    Apache 2.0

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/cfdude/super-shell-mcp'

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