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

ssh_session_send

Write commands or control signals (such as Ctrl+C) to a persistent SSH PTY session and collect incremental terminal output. Detect command completion or shell prompts in long-running sessions.

Instructions

向指定的持久 PTY 终端写入指令或控制信号(如 '\x03' 发送 Ctrl+C),并收集增量屏幕回显

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": {
      "sessionId": "<sessionId>",
      "input": "<input>"
    },
    "name": "ssh_session_send"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes待发送的数据内容或控制字符(如 '\x03' 发送 Ctrl+C)
sessionIdYes目标持久 PTY 终端会话 ID
timeoutMsNo当指定 expectPattern 时,最长等待模式匹配超时时间(毫秒),默认 30000ms (30秒)
waitForMsNo若未指定 expectPattern,等待收集终端响应输出的时间(毫秒),默认 1000ms
expectPatternNo用于主动检测命令完成或 Shell 提示符的正则表达式模式字符串(如 '[$#>:]\s*$'),匹配即刻响应返回

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.1
    • addedInput schema / properties / expectPattern
      Added value: +{
      +  "description": "用于主动检测命令完成或 Shell 提示符的正则表达式模式字符串(如 '[$#>:]\\s*$'),匹配即刻响应返回",
      +  "type": "string"
      +}
    • addedInput schema / properties / timeoutMs
      Added value: +{
      +  "default": 30000,
      +  "description": "当指定 expectPattern 时,最长等待模式匹配超时时间(毫秒),默认 30000ms (30秒)",
      +  "exclusiveMinimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / waitForMs / description
      Previous value: -"等待收集终端响应输出的时间(毫秒),默认 1000ms"New value: +"若未指定 expectPattern,等待收集终端响应输出的时间(毫秒),默认 1000ms"
  2. First observedv1.2.5

TDQS

B3.2/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden; it does disclose the core behavior of writing input and gathering incremental screen echo, which is useful. However it omits blocking semantics, whether writes mutate persistent session state, and any permission requirements — significant gaps for an interactive write 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.

Conciseness4/5

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

A single dense sentence with the action front-loaded and no filler; the parenthetical control-character example is directly useful. Slightly compressed for the number of behaviors it touches, but well-structured.

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?

With 5 parameters, no annotations, and no output schema, the description is adequate but lean. It covers the input/echo loop yet leaves out how the call blocks, when it returns, and how it relates to sibling session/exec tools, leaving clear gaps for a fairly complex interactive tool.

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 sessionId, input, timeoutMs, waitForMs, and expectPattern. The description's Ctrl+C example duplicates the schema's own input description and adds no new parameter meaning, 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 states a specific verb (写入/write) and resource (指定的持久 PTY 终端) plus what it returns (增量屏幕回显), so an agent knows this drives an interactive terminal rather than a one-shot exec. It doesn't explicitly name ssh_exec or ssh_session_start as the contrasting sibling, keeping it below 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?

There is no when-to-use, when-not-to-use, or alternative guidance. The agent must infer from the 'persistent PTY' framing that this is for interactive/long-lived sessions rather than ssh_exec, but nothing states that routing rule.

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