Skip to main content
Glama
xiao-linxin

mcp-ssh

by xiao-linxin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

MCP SSH Server

一个基于 expect + Python MCP 的 SSH 持久连接方案，专为 JumpServer 堡垒机设计。

解决传统 SSH MCP 工具无法通过交互式堡垒机保持长连接的问题。

特性

  • 多堡垒机支持 - 一个配置文件管理多台 JumpServer 和多台目标服务器

  • 持久长连接 - 每个连接对应独立 expect 子进程，长期存活无需反复鉴权

  • 并发执行 - 同时连接多台服务器，各自独立互不干扰

  • 热加载 - 修改配置或模板后无需重启，下次调用自动生效

  • 双认证模式 - 支持 SSH 密钥和密码两种认证方式

  • 快速响应 - 使用 marker 分割技术，命令执行后立即返回输出

Related MCP server: mcp-jumpserver-gui-sucks

架构

┌─────────────────────────────────────────────────────────────┐
│                    Claude Code / MCP Client                  │
└──────────────────────────┬──────────────────────────────────┘
                           │ stdio JSON-RPC
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                   MCP SSH Server (Python)                    │
│  ┌──────────────────┐    ┌──────────────────────────────┐  │
│  │ SessionManager   │    │   config.json (热加载)        │  │
│  │ ├─ connect()     │◄──►│   bastions[] → servers[]     │  │
│  │ ├─ execute()     │    └──────────────────────────────┘  │
│  │ └─ close()       │                                       │
│  └────────┬─────────┘                                       │
│           │ spawn + pipe                                     │
│           ▼                                                  │
│  ┌──────────────────────────────────────────────────────┐   │
│  │         expect_template.py (热加载)                    │   │
│  │         生成 expect 脚本处理交互式认证                  │   │
│  └────────┬─────────────────────────────────────────────┘   │
└───────────┼──────────────────────────────────────────────────┘
            │ spawn expect
            ▼
┌─────────────────────────────────────────────────────────────┐
│                    expect 进程 (per session)                  │
│  ┌─────────────────┐                                        │
│  │ spawn ssh       │──→ JumpServer → 目标服务器              │
│  │ stdin pipe      │◄── 接收 Python 发来的命令               │
│  │ stdout pipe     │── 输出到 Python reader 线程             │
│  └─────────────────┘                                        │
└─────────────────────────────────────────────────────────────┘

安装

前置要求

  • Python 3.10+

  • expect (系统命令)

  • uv (推荐的 Python 包管理器)

安装 expect

macOS:

brew install expect

Ubuntu/Debian:

sudo apt-get install expect

CentOS/RHEL:

sudo yum install expect

安装项目

cd a-mcp/mcp-ssh
uv sync

配置

复制配置示例并修改：

cp config.example.json config.json

配置示例

{
  "bastions": [
    {
      "id": "bastion-01",
      "host": "bastion.example.com",
      "port": 22,
      "user": "your_username",
      "auth_type": "key",
      "key_path": "~/.ssh/your_key.pem",
      "password": "",
      "default": true,
      "servers": [
        {
          "id": "server-01",
          "name": "应用服务器 1",
          "search": "/192.168.1.100",
          "asset_id": "1",
          "target_dir": "/var/www/app1"
        },
        {
          "id": "server-02",
          "name": "应用服务器 2",
          "search": "/192.168.1.101",
          "asset_id": "2",
          "target_dir": "/var/www/app2"
        }
      ]
    },
    {
      "id": "direct-server",
      "host": "direct.example.com",
      "port": 22,
      "user": "your_username",
      "auth_type": "password",
      "key_path": "",
      "password": "your_password",
      "default": false,
      "servers": []
    }
  ]
}

配置说明

字段

类型

说明

id

string

唯一标识符

host

string

服务器地址

port

int

SSH 端口（默认 22）

user

string

用户名

auth_type

string

认证方式：key 或 password

key_path

string

SSH 私钥路径（auth_type=key 时必填）

password

string

密码（auth_type=password 时必填）

default

bool

是否为默认堡垒机

servers

array

该堡垒机下的目标服务器列表

服务器配置 (servers[]):

字段

类型

说明

id

string

服务器唯一 ID（用于 ssh_connect）

name

string

服务器名称（描述用）

search

string

JumpServer 搜索关键词（如 /192.168.1.100）

asset_id

string

JumpServer 资产 ID

target_dir

string

登录后切换的工作目录

使用方法

作为 MCP 服务

在 Claude Code 或其他 MCP 客户端中配置：

{
  "mcpServers": {
    "ssh": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/mcp-ssh", "python", "mcp_ssh_server.py"]
    }
  }
}

MCP 工具列表

工具

说明

ssh_connect

通过配置连接服务器（推荐）

ssh_connect_raw

直接指定参数连接（临时使用）

ssh_execute

在会话中执行命令

ssh_read_output

读取会话缓冲区输出

ssh_close

关闭会话

ssh_list_sessions

列出所有活跃会话

ssh_list_servers

列出配置中的所有服务器

使用示例

1. 连接服务器

# 使用配置中的服务器 ID
ssh_connect(server_id="server-01")

# 或直接指定参数
ssh_connect_raw(
    host="example.com",
    port=22,
    user="admin",
    password="secret",
    search="",  # 直连模式
    target_dir="/home/admin"
)

2. 执行命令

ssh_execute(session_id="session_1", command="ls -la")
ssh_execute(session_id="session_1", command="df -h")

3. 管理会话

# 查看所有活跃会话
ssh_list_sessions()

# 关闭指定会话
ssh_close(session_id="session_1")

项目结构

mcp-ssh/
├── mcp_ssh_server.py        # MCP 服务主入口 + SessionManager
├── expect_template.py       # expect 脚本模板（支持热加载）
├── config.json              # 多堡垒机 + 多资产配置（需自行创建）
├── config.example.json      # 配置示例
├── pyproject.toml           # Python 项目配置
├── uv.lock                  # 依赖锁定
├── ARCHITECTURE.md          # 详细架构文档
└── README.md                # 本文件

开发指南

本地测试

cd a-mcp/mcp-ssh
uv run python mcp_ssh_server.py

热加载机制

  • config.json - 每次调用 ssh_connect 或 ssh_list_servers 时检查修改时间，变更则重新加载

  • expect_template.py - 每次生成 expect 脚本时检查修改时间，变更则重新加载模块

修改后无需重启服务，下次调用自动生效。

添加新服务器

在 config.json 的 servers 数组中添加条目：

{
  "id": "new-server",
  "name": "新服务器",
  "search": "/10.0.0.100",
  "asset_id": "1",
  "target_dir": "/opt/app"
}

修改 expect 行为

编辑 expect_template.py 的 build_expect_script() 函数，修改后即时生效。

常见问题

Q: 为什么用 expect 而不是 ssh2 库？

JumpServer 堡垒机是交互式菜单程序，不是标准 SSH 跳板机。它禁止 ProxyJump 和端口转发，只能通过模拟键盘输入来操作。expect 是处理这种场景的最可靠方式。

Q: 连接断了怎么办？

使用 ssh_list_sessions 查看会话状态。如果状态是 closed 或 error，重新调用 ssh_connect 即可。

Q: 输出有 ANSI 乱码？

SSH 通过 PTY 传输，会带终端控制字符。这是正常的，命令输出本身不受影响。

Q: 如何调试 expect 脚本？

在 expect_template.py 的关键步骤前添加：

'send_user "DEBUG: 当前步骤\\n"',
"flush stdout",

热加载会自动生效。

许可证

MIT

贡献

欢迎提交 Issue 和 Pull Request！

Available Tools

7 tools
ssh_closeB

关闭指定的 SSH 会话。

ParametersJSON Schema
NameRequiredDescriptionDefault
session_idYes要关闭的会话 ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'close' without disclosing side effects, required session state, or error behavior. Minimal transparency beyond the obvious.

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?

Single sentence with no redundancy. Front-loaded with verb and resource, very efficient.

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?

Description covers basic purpose but lacks usage guidelines and behavioral transparency. For a simple tool with output schema, it is minimally adequate but not fully 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 description adds no extra meaning beyond the parameter description already in the schema. Baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool closes a specified SSH session, with a specific verb and resource. It distinguishes itself from sibling tools like ssh_list_sessions and ssh_connect.

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 on when to use this tool versus alternatives, such as when to close a session versus executing commands. No prerequisites or exclusions are mentioned.

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

ssh_connectC

通过 config.json 配置连接 JumpServer 堡垒机并建立持久 SSH 会话。

ParametersJSON Schema
NameRequiredDescriptionDefault
timeoutNo连接超时秒数
server_idYes配置中的服务器 ID（如 dev1-api、dev1-go-mid），见 ssh_list_servers

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 bears full burden. It mentions persistent SSH session but does not disclose authentication requirements, side effects, or what happens after connection. Incomplete for behavioral understanding.

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

Conciseness3/5

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

Single sentence, no waste, but lacks important details like usage context or behavioral notes. Adequate length but functional gaps reduce conciseness effectiveness.

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?

Given an output schema exists (not shown), description needn't explain return values. Parameters are covered. However, missing usage guidelines and behavioral transparency leave completeness lacking for a connection 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 coverage is 100%, and the description adds no extra meaning beyond the schema definitions. Parameters are well-documented in the schema, so baseline 3 is appropriate.

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 connects to JumpServer bastion host via config.json and establishes a persistent SSH session. The verb 'connect' and resource are clear, but it does not explicitly distinguish from ssh_connect_raw, which limits it to a 4.

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 on when to use this tool versus alternatives like ssh_connect_raw. No prerequisites or exclusions mentioned. The agent must infer usage context from tool name and sibling list.

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

ssh_connect_rawB

直接指定参数连接（不依赖 config.json），用于临时连接。

ParametersJSON Schema
NameRequiredDescriptionDefault
hostNo堡垒机地址service.rrzuji.net
nameNo会话名称（可选）
portNo堡垒机端口
userNo堡垒机用户名xiaolinxin
proxyNoSOCKS5 代理地址
searchNo搜索字符串，如 /39.108.73.45/39.108.73.45
timeoutNo连接超时秒数
key_pathNoSSH 私钥路径（auth_type=key 时使用）
passwordNo堡垒机密码
auth_typeNo认证方式 (password/key)password
server_idNo目标资产 ID1
target_dirNo登录后工作目录

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 bears full responsibility. It only repeats the tool's basic function ('connect directly with parameters') and fails to disclose behavioral traits such as authentication requirements, side effects, or error handling.

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?

The description is a single, concise sentence that conveys the core differentiator. While brief, it is efficient with no wasted words, though it could be slightly more structured.

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?

With 12 parameters and an output schema (not shown), the description is too minimal. It omits details about return values, connection behavior, and error conditions, leaving the agent with incomplete context for a complex 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?

All 12 parameters are documented in the input schema with descriptions and defaults, so schema coverage is 100%. The description adds no additional parameter context beyond what the schema already provides, which is adequate.

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 connects directly with parameters without relying on config.json, and is for temporary connections. This differentiates it from sibling tools like ssh_connect, giving a specific verb and resource.

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?

The description implies usage context (temporary connections, direct parameters) but does not explicitly state when to avoid this tool or mention alternatives like ssh_connect for config-based connections.

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

ssh_executeB

在已建立的 SSH 会话中执行命令并返回输出。

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYes要执行的 shell 命令
timeoutNo命令超时毫秒数
session_idYes会话 ID（由 ssh_connect 返回）

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states it executes and returns output, but does not mention potential side effects (e.g., session state changes), blocking behavior, security considerations, or that commands may be destructive. The timeout parameter hints at behavior but is not explained.

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 sentence that front-loads the verb and resource. It contains no redundant words and is efficiently structured for quick parsing.

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?

Despite having an output schema and three parameters, the description lacks critical context: no explanation of return value format (though output schema may cover this), no mention of error handling, timeouts beyond parameter, or prerequisites. With no annotations, the description is insufficient for an agent to fully understand the behavior.

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 baseline is 3. The description does not add meaning beyond the schema: the parameter descriptions in the input schema already explain 'command', 'timeout', and 'session_id' sufficiently. The overall description only restates the tool purpose without enriching parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes commands in an established SSH session and returns output. The verb 'execute' and resource 'command in SSH session' are specific, and it helps distinguish from sibling tools like ssh_connect (creates sessions) and ssh_close (closes sessions).

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?

The description implies usage after establishing a session ('in an established SSH session'), but it does not explicitly state when to use this tool versus alternatives like ssh_read_output, nor does it provide when-not-to-use or alternative guidance. The context is understood but not explicit.

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

ssh_list_serversA

列出 config.json 中所有可用的服务器配置。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes a read-only listing operation but lacks details about potential errors (e.g., missing config.json) or side effects. For a simple list tool, this is adequate but not comprehensive.

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 no unnecessary words. It is well-structured and front-loaded with the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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

For a simple list tool with an output schema (not shown), the description adequately conveys the function. It could mention prerequisites or implications of 'available,' but given the tool's straightforward nature, it is sufficiently complete.

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 no parameters, and the schema coverage is 100% (empty schema). The description adds no further parameter information, which is acceptable given the lack of parameters. Baseline for zero params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists all available server configurations from config.json. The verb 'list' and resource 'server configurations' are specific, and it is distinct from sibling tools like ssh_connect or ssh_execute.

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?

The description provides the tool's purpose but does not explicitly state when to use it over alternatives. However, the context of sibling tools (e.g., ssh_connect) implies its use for viewing available servers before connecting.

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

ssh_list_sessionsA

列出所有当前活跃的 SSH 会话及其状态。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool lists sessions and status but omits details like authentication requirements, response format for empty results, or potential side effects.

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 no wasted words. It front-loads the purpose and is appropriately sized for a simple zero-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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

Given the tool's simplicity (no parameters, output schema exists), the description is adequate. It covers the core functionality, and the output schema presumably documents the return values. Slight gap in behavioral details is mitigated by the straightforward nature of the operation.

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 no parameters, so the description correctly omits parameter details. Schema coverage is 100% (empty object), and the description adds no misleading or extra information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: listing active SSH sessions and their status. It uses a specific verb ('list') and resource ('SSH sessions'), and distinguishes from sibling tools by focusing on sessions rather than servers or connections.

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?

The description implies usage for viewing active sessions but does not explicitly state when to use this tool versus alternatives like ssh_list_servers or ssh_connect. No when-not-to or alternative guidance is provided.

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

ssh_read_outputA

读取 SSH 会话缓冲区中的最新输出（不发送新命令）。

ParametersJSON Schema
NameRequiredDescriptionDefault
session_idYes会话 ID（由 ssh_connect 返回）

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

No annotations provided. Description discloses it does not send commands, but does not mention side effects, error states, or behavior with empty buffer.

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?

Single sentence, no redundancy, action first, perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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

Given output schema exists, the description covers core functionality. Lacks mention of return type but output schema fills that gap.

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% and already explains the session_id parameter. The tool description adds no extra parameter context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it reads the latest SSH session buffer output without sending a new command, distinguishing it from ssh_execute.

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

Usage Guidelines4/5

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

The description implies usage after a command is executed, but lacks explicit when-to-use and alternatives guidance. Still, it contrasts with sending commands.

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.

  1. 7 tool updatesv1.0.0
    • First observedssh_close
    • First observedssh_connect
    • First observedssh_connect_raw
    • First observedssh_execute
    • First observedssh_list_servers
    • First observedssh_list_sessions
    • First observedssh_read_output
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: connecting (two variants), closing, executing, listing servers, listing sessions, and reading output. No overlaps.

Naming Consistency5/5

All tools follow the pattern 'ssh_<action>' or 'ssh_<verb>_<noun>'. The naming is consistent and predictable.

Tool Count5/5

Seven tools cover the core operations for SSH session management without being excessive or insufficient.

Completeness5/5

The set includes connection, execution, session listing, and buffer reading. For the intended domain (interactive SSH via JumpServer), no obvious gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP SSH Tools Server

    nwnusun-cool
    F
    license
    A
    quality
    F
    maintenance
    A server based on the MCP framework that provides remote server management capabilities through SSH, supporting features like connection pooling, file transfers, and remote command execution.
    7
    -

  • mcp-jumpserver-gui-sucks

    ArtiPyHeart
    A
    license
    B
    quality
    A
    maintenance
    A JumpServer 443-only MCP bridge for coding agents that exposes a CLI-first, MFA-compatible, audit-preserving path into JumpServer assets without GUI or port 2222 dependencies.
    37
    1
    MIT

  • ssh-mcp-server

    wijzeu
    A
    license
    Not graded
    quality
    C
    maintenance
    SSH-based MCP server that enables remote execution of SSH commands, file transfers, and secure server management via the MCP protocol.
    ISC

  • open-ssh-mcp

    cjp1016
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server for managing remote SSH servers, enabling AI agents to execute commands, transfer files, and perform deployment operations securely.
    MIT