一个 MCP（模型上下文协议）服务器，用于跨多个平台（Windows、macOS、Linux）执行 Shell 命令。该服务器内置白名单和审批机制，提供了一种安全的 Shell 命令执行方式。
在 Windows、macOS 和 Linux 上通过 MCP 执行 shell 命令
自动平台检测和 shell 选择
支持多个 shell：
Windows ：cmd.exe、PowerShell
macOS ：zsh、bash、sh
Linux ：bash、sh、zsh
具有安全级别的命令白名单：
安全：无需批准即可执行的命令
需要批准：执行前需要明确批准的命令
禁止：明确阻止的命令
特定于平台的命令白名单
针对潜在危险命令的非阻塞审批工作流程
具有基于文件的日志的综合日志系统
全面的命令管理工具
用于诊断的平台信息工具
Related MCP server: Mac Shell MCP Server
要通过Smithery自动为 Claude Desktop 安装 Super Shell MCP Server：
npx -y @smithery/cli install @cfdude/super-shell-mcp --client claude# 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 buildnpm start或者直接：
node build/index.jsRoo Code 和 Claude Desktop 的 MCP 服务器配置格式类似。以下是设置 Super Shell MCP 服务器的方法：
使用 Super Shell MCP 最简单的方法是使用 NPX，它会自动从 npm 安装并运行该软件包，无需手动设置。该软件包可在 NPM 上的https://www.npmjs.com/package/super-shell-mcp获取。
"super-shell": {
"command": "npx",
"args": [
"-y",
"super-shell-mcp"
],
"alwaysAllow": [],
"disabled": false
}"super-shell": {
"command": "npx",
"args": [
"-y",
"super-shell-mcp"
],
"alwaysAllow": false,
"disabled": false
}如果您更喜欢使用本地安装，请将以下内容添加到您的 Roo Code MCP 设置配置文件（位于~/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
}您可以选择通过添加 shell 参数来指定自定义 shell：
"super-shell": {
"command": "node",
"args": [
"/path/to/super-shell-mcp/build/index.js",
"--shell=/usr/bin/bash"
],
"alwaysAllow": [],
"disabled": false
}Windows 11 示例
"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"
],
"alwaysAllow": [],
"disabled": false
}将以下内容添加到您的 Claude Desktop 配置文件（位于~/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
}对于 Windows 用户，配置文件通常位于%APPDATA%\Claude\claude_desktop_config.json 。
默认 shell：cmd.exe（或 PowerShell，如果可用）
配置路径：
Roo 代码： %APPDATA%\Code\User\globalStorage\rooveterinaryinc.roo-cline\settings\cline_mcp_settings.json
克劳德桌面： %APPDATA%\Claude\claude_desktop_config.json
Shell 路径示例：
cmd.exe： C:\\Windows\\System32\\cmd.exe
PowerShell： C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe
PowerShell 核心： C:\\Program Files\\PowerShell\\7\\pwsh.exe
默认 shell：/bin/zsh
配置路径：
Roo 代码： ~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json
Claude 桌面： ~/Library/Application Support/Claude/claude_desktop_config.json
Shell 路径示例：
zsh： /bin/zsh
庆典： /bin/bash
sh： /bin/sh
默认 shell：/bin/bash（或 $SHELL 环境变量）
配置路径：
Roo 代码： ~/.config/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json
克劳德桌面： ~/.config/Claude/claude_desktop_config.json
Shell 路径示例：
庆典： /bin/bash
sh： /bin/sh
zsh： /usr/bin/zsh
您可以选择指定自定义 shell：
"super-shell": {
"command": "node",
"args": [
"/path/to/super-shell-mcp/build/index.js",
"--shell=C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
],
"alwaysAllow": false,
"disabled": false
}将/path/to/super-shell-mcp替换为您克隆存储库的实际路径。
笔记：
对于 Roo 代码：出于安全考虑，建议将
alwaysAllow设置为空数组[]，因为它会在执行任何命令之前提示您批准。如果您想允许特定命令而不提示，可以将这些命令的名称添加到数组中，例如："alwaysAllow": ["execute_command", "get_whitelist"]。对于 Claude Desktop：出于安全考虑，建议
alwaysAllow设置为falseDesktop 使用布尔值而不是数组，其中false表示所有命令都需要批准，true表示所有命令均允许，无需提示。重要提示：
alwaysAllow参数由 MCP 客户端（Roo Code 或 Claude Desktop）处理，而非 Super Shell MCP 服务器本身。服务器无论使用哪种格式都能正常工作，因为客户端会在向服务器发送请求之前处理审批流程。
该服务器公开以下 MCP 工具：
get_platform_info获取有关当前平台和 shell 的信息。
{}execute_command在当前平台上执行shell命令。
{
"command": "ls",
"args": ["-la"]
}get_whitelist获取白名单命令列表。
{}add_to_whitelist将命令添加到白名单。
{
"command": "python3",
"securityLevel": "safe",
"description": "Run Python 3 scripts"
}update_security_level更新白名单命令的安全级别。
{
"command": "python3",
"securityLevel": "requires_approval"
}remove_from_whitelist从白名单中删除命令。
{
"command": "python3"
}get_pending_commands获取待批准的命令列表。
{}approve_command批准待处理的命令。
{
"commandId": "command-uuid-here"
}deny_command拒绝待处理的命令。
{
"commandId": "command-uuid-here",
"reason": "This command is potentially dangerous"
}该服务器包括根据检测到的平台自动选择的平台特定的命令白名单。
echo将文本打印到标准输出
ls列出目录内容
pwd打印工作目录
echo将文本打印到标准输出
cat连接并打印文件
grep在文件中搜索模式
find在目录层次结构中查找文件
cd更改目录
head输出文件的第一部分
tail输出文件的最后部分
wc打印换行符、字数和字节数
dir列出目录内容
type显示文本文件的内容
findstr在文件中搜索字符串
where定位程序
whoami显示当前用户
hostname显示计算机名称
ver显示操作系统版本
copy ——复制文件
move ——移动文件
mkdir创建目录
rmdir删除目录
rename ——重命名文件
attrib更改文件属性
mv移动（重命名）文件
cp复制文件和目录
mkdir创建目录
touch更改文件时间戳或创建空文件
chmod更改文件模式位
chown更改文件所有者和组
del删除文件
erase ——删除文件
format ——格式化磁盘
runas以另一个用户身份执行程序
rm删除文件或目录
sudo以另一个用户身份执行命令
所有命令均以运行 MCP 服务器的用户权限执行
需要批准的命令将被保留在队列中，直到明确批准
禁止的命令永远不会执行
服务器使用 Node.js 的execFile而不是exec来防止 shell 注入
指定时，根据允许的模式验证参数
您可以使用add_to_whitelist工具扩展白名单。例如：
{
"command": "npm",
"securityLevel": "requires_approval",
"description": "Node.js package manager"
}Super Shell MCP 可作为 npm 包在https://www.npmjs.com/package/super-shell-mcp上获取。
使用 NPX 方法（如配置部分的选项 1 所示）有几个优点：
无需手动设置：无需克隆存储库、安装依赖项或构建项目
自动更新：始终使用最新发布的版本
跨平台兼容性：在 Windows、macOS 和 Linux 上以相同的方式运行
简化配置：更短的配置，没有绝对路径
减少维护：无需管理或更新本地文件
如果您希望直接从 GitHub 使用最新的开发版本：
"super-shell": {
"command": "npx",
"args": [
"-y",
"github:cfdude/super-shell-mcp"
],
"alwaysAllow": [], // For Roo Code
"disabled": false
}如果你想将自己修改的版本发布到 npm：
使用您的详细信息更新 package.json
确保“bin”字段配置正确：
"bin": {
"super-shell-mcp": "./build/index.js"
}发布到 npm：
npm publish为了使用 NPX 与 MCP 客户端实现最佳集成，该项目遵循以下最佳实践：
可执行入口点：主文件包含一个 shebang 行（ #!/usr/bin/env node ）并在构建期间可执行。
包装配置：
"type": "module" - 确保使用 ES 模块
"bin"字段——将命令名称映射到入口点
"files"字段 - 指定发布时要包含的文件
"prepare"脚本 - 确保编译在安装时进行
TypeScript配置：
"module": "NodeNext" - 正确的 ES 模块支持
"moduleResolution": "NodeNext" - 与 ES 模块一致
自动安装和执行：
MCP 客户端配置使用npx -y自动安装并运行包
由于进程在后台运行，因此无需占用任何终端窗口
出版流程：
# Update version in package.json
npm version patch # or minor/major as appropriate
# Build and publish
npm publish这些做法确保了 MCP 服务器可以由 MCP 客户端自动启动，而无需单独的终端窗口，从而提高了用户体验和操作效率。
PowerShell 脚本执行策略
问题：PowerShell 可能会阻止脚本执行，并出现错误“此系统上已禁用脚本执行”
解决方案：以管理员身份运行 PowerShell 并执行Set-ExecutionPolicy RemoteSigned或在配置 shell 时使用-ExecutionPolicy Bypass参数
路径分隔符
问题：Windows 在路径中使用反斜杠 ( \ )，需要在 JSON 中进行转义
解决方案：在 JSON 配置文件中使用双反斜杠（ \\ ），例如C:\\Windows\\System32\\cmd.exe
未找到命令
问题：Windows 没有ls 、 grep等 Unix 命令。
解决方案：使用 Windows 等效项（使用dir代替ls ，使用findstr代替grep ）
Shell 权限
问题：执行命令时权限被拒绝
解决方案：使用chmod +x /path/to/shell确保 shell 具有适当的权限
环境变量
问题：MCP 服务器中没有可用的环境变量
解决方案：在 shell 的配置文件（ .zshrc 、 .bashrc等）中设置环境变量
Shell 检测问题
问题：服务器无法检测正确的shell
解决方案：在配置中明确指定shell路径
命令执行超时
问题：命令执行时间过长且超时
解决方案：增加命令服务构造函数中的超时值
该服务器包括一个全面的日志系统，可将日志写入文件以便于调试和监控：
日志文件位置
默认值：服务器目录中的logs/super-shell-mcp.log
日志目录由 Git 自动创建并跟踪（使用 .gitkeep 文件）
日志文件本身通过 .gitignore 从 Git 中排除
包含有关服务器操作、命令执行和审批工作流程的详细信息
日志级别
INFO ：一般操作信息
DEBUG ：详细的调试信息
ERROR ：错误条件和异常
查看日志
使用标准文件查看命令检查日志：
# View the entire log
cat logs/super-shell-mcp.log
# Follow log updates in real-time
tail -f logs/super-shell-mcp.log日志内容
服务器启动和配置
命令执行请求和结果
批准工作流事件（待定、已批准、已拒绝）
错误情况和故障排除信息
白名单管理
问题：需要将自定义命令添加到白名单
解决方案：使用add_to_whitelist工具添加特定于您的环境的命令
此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。更多详情，请参阅项目仓库中的 LICENSE 文件。
Add a command to the whitelist
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to whitelist | |
| securityLevel | Yes | Security level for the command | |
| description | No | Description of the command |
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.
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.
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.
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.
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.
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 a pending command
| Name | Required | Description | Default |
|---|---|---|---|
| commandId | Yes | ID of the command to approve |
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.
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.
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.
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.
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.
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 a pending command
| Name | Required | Description | Default |
|---|---|---|---|
| commandId | Yes | ID of the command to deny | |
| reason | No | Reason for denial |
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.
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.
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.
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.
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.
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 a shell command on the current platform
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to execute | |
| args | No | Command arguments |
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.
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.
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.
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.
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.
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 the list of commands pending approval
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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 information about the current platform and shell
| 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 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.
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.
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.
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.
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.
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 the list of whitelisted commands
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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 a command from the whitelist
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to remove from whitelist |
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.
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.
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.
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.
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.
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 the security level of a whitelisted command
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to update | |
| securityLevel | Yes | New security level for the command |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
add_to_whitelistapprove_commanddeny_commandexecute_commandget_pending_commandsget_platform_infoget_whitelistremove_from_whitelistupdate_security_levelEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
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