Skip to main content
Glama
mcp-server-ssh
by atengk

ssh_batch_exec

Execute Bash/Shell commands across multiple Linux hosts in parallel or serial, with host selectors, concurrency limits, sudo, and output truncation.

Instructions

向多台目标 Linux 主机批量分发执行无状态 Bash/Shell 命令(支持 @all_active、@all_configured、通配符、并发限流、串行中断及 16KB 紧凑输出截断)

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>",
      "targets": "<targets>"
    },
    "name": "ssh_batch_exec"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdNo初始执行工作目录(自动包装为 cd <cwd> && <command>)
envNo注入远程环境的环境变量键值对
modeNo批量调度模式:parallel(受控并发,默认)或 serial(顺序串行)parallel
sudoNo是否以 sudo 特权身份执行命令(默认 false)。若为 true,自动通过 SSH Channel Stdin 管道流式安全注入提权密码,零命令行明文泄露
dryRunNo是否仅通过安全拦截守卫检测合规性,而不真正下发执行,默认 false
commandYes待在远程 Linux 系统执行的 Bash/Shell 命令
rawExecNo是否绕过登录 Shell 包装(bash -l -c),直接以非登录 Shell 原生执行,默认 false
targetsYes目标主机选择器列表(支持主机别名、连接 ID、'@all_active'、'@all_configured' 或通配符如 'web-*')
timeoutMsNo执行超时时间(毫秒),默认 60000ms (1分钟)
concurrencyNoparallel 并发模式下的最大并发数上限(1-20,默认 5)
stopOnErrorNoserial 串行模式下遇到节点失败或非 0 退出码时是否立即中断后续节点执行(默认 false)
sudoPasswordNosudo 提权专用密码。若未提供,则自动复用当前 SSH 连接的登录密码
dangerouslySkipSafetyCheckNo是否强制跳过前置高危安全拦截规则(危险操作逃生门,需同时配置环境变量 SSH_ALLOW_DANGEROUS_COMMANDS=true 授权)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the burden but does disclose genuinely useful traits: stateless execution (no persistent session), concurrency throttling, serial interruption, and 16KB output truncation — the truncation caveat especially matters to an agent parsing results. It says nothing about partial-failure semantics, result aggregation across hosts, or the sudo/safety-guard behavior, which are significant for a 13-parameter mutation tool.

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

Conciseness4/5

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

A single front-loaded sentence with verb and scope first, then capabilities in a parenthetical. Dense but every clause carries information; the parenthetical stack is slightly heavy but not wasteful.

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 13-parameter tool with nested objects, no annotations, and no output schema, the description is thin: it never explains the shape of batch results (per-host success/failure, truncated output), nor error handling across hosts. The rich schema compensates for parameter-level gaps, making it barely adequate rather than complete.

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 every parameter including mode, sudo, dryRun, and concurrency is already documented in the schema. The description echoes the target selector forms (@all_active, @all_configured, wildcards) but adds no syntax or precedence detail beyond the schema. 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?

Names a specific verb (batch distribute/execute) and resource (stateless Bash/Shell commands) with an explicit multi-host scope, which distinguishes it from single-host ssh_exec in the sibling list. It stops short of naming the sibling, so an agent must infer the boundary from '多台目标'.

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 by '多台目标 Linux 主机' — an agent can infer batch versus single-host, but nothing states when to prefer this over ssh_exec, ssh_job_start, or ssh_session_start, and no prerequisites or exclusions are given.

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