Skip to main content
Glama
Sign In
mcp-server-ssh

mcp-server-ssh

by atengk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ssh_exec

Execute a single stateless Bash/Shell command on a remote Linux host and return its exit code, standard output, and standard error.

Instructions

在远程 Linux 主机执行单次无状态 Bash/Shell 命令，精准返回退出码、标准输出与标准错误

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>"
    },
    "name": "ssh_exec"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdNo初始执行工作目录（自动包装为 cd <cwd> && <command>）
envNo注入远程环境的环境变量键值对
sudoNo是否以 sudo 特权身份执行命令（默认 false）。若为 true，自动通过 SSH Channel Stdin 管道流式安全注入提权密码，零命令行明文泄露
dryRunNo是否仅通过安全拦截守卫检测合规性，而不真正下发执行，默认 false
commandYes待在远程 Linux 系统执行的 Bash/Shell 命令
rawExecNo是否绕过登录 Shell 包装（bash -l -c），直接以非登录 Shell 原生执行，默认 false
timeoutMsNo执行超时时间（毫秒），默认 60000ms (1分钟)
connectionIdNo目标连接标识符，缺省时自动路由至当前默认活跃连接
sudoPasswordNosudo 提权专用密码。若未提供，则自动复用当前 SSH 连接的登录密码
dangerouslySkipSafetyCheckNo是否强制跳过前置高危安全拦截规则（危险操作逃生门，需同时配置环境变量 SSH_ALLOW_DANGEROUS_COMMANDS=true 授权）

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.1
    • addedInput schema / properties / sudo
      Added value: +{
+  "default": false,
+  "description": "是否以 sudo 特权身份执行命令（默认 false）。若为 true，自动通过 SSH Channel Stdin 管道流式安全注入提权密码，零命令行明文泄露",
+  "type": "boolean"
+}
    • addedInput schema / properties / sudoPassword
      Added value: +{
+  "description": "sudo 提权专用密码。若未提供，则自动复用当前 SSH 连接的登录密码",
+  "type": "string"
+}
  2. First observedv1.2.5

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden and does contribute key facts: the execution is stateless and it returns exit code, stdout and stderr. However it says nothing about the side-effecting/destructive nature of arbitrary command execution, the sudo/safety-guard behavior, or the dangerous-command bypass hinted at by the schema.

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?

A single front-loaded sentence with zero filler that states verb, resource, execution model and return contract in one pass. Everything in it earns its place.

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 complex 10-parameter tool with no annotations and no output schema, the description usefully covers the return contract (exit code/stdout/stderr) which compensates for the missing output schema. It is still thin on behavioral caveats for such a powerful, side-effecting tool, leaving it only minimum-viable.

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 all ten parameters in detail (cwd wrapping, sudo, dryRun, timeoutMs, rawExec, etc.). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 names a specific verb (执行/execute) and resource (single stateless Bash/Shell command on a remote Linux host), and the word '无状态' (stateless) subtly separates it from session/job siblings. It stops short of naming an actual sibling like ssh_session_send or ssh_job_start, so differentiation is implied rather than explicit.

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

Usage Guidelines3/5

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

Usage is only implied: '单次无状态' (single, stateless) signals this is for one-off commands rather than persistent sessions, which hints at when it applies versus ssh_session_send or ssh_job_start. There is no explicit when-to-use/when-not statement or named alternative.

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

Deploy Server

Other Tools