de en es ja ko ru zh

RemoteShell MCP

Name: RemoteShell MCP
Author: chouzz

by chouzz

Overview Schema Source Related Servers Discussions Admin

Python

Local

🔗 RemoteShell MCP

一个 Model Context Protocol (MCP) 服务器，使 LLM 能够安全地管理和执行远程 SSH 服务器上的命令。

✨ 功能

🔐 安全凭据管理 - 保存一次 SSH 服务器配置，无需重新输入凭据
💻 远程命令执行 - 远程执行非交互式 shell 命令
📁 文件操作 - 通过 SFTP 上传/下载文件
🤖 LLM 驱动 - 基于 FastMCP 和 Paramiko 构建

Related MCP server: ssh-client-mcp-server

🚀 安装

RemoteShell 是一个通过 PyPI 分发的 stdio MCP 服务器。直接使用 uvx 运行它 — 无需安装步骤。然后将服务器注册到你的 AI 编码代理：

Claude Code

claude mcp add remoteshell --scope user -- uvx remoteshell-mcp

Codex

codex mcp add remoteshell -- uvx remoteshell-mcp

其他代理 — 点击对应的代理以展开 👇

cursor mcp add remoteshell -- uvx remoteshell-mcp

编辑 ~/.gemini/config/mcp_config.json（全局）或 .agents/mcp_config.json（项目）：

{
  "mcpServers": {
    "remoteshell": {
      "command": "uvx",
      "args": ["remoteshell-mcp"]
    }
  }
}

或者在 Antigravity TUI 中打开 MCP Servers 视图并运行 /mcp 命令。

opencode mcp add

选择 local，然后输入 uvx remoteshell-mcp。

编辑 ~/.hermes/config.yaml：

mcp_servers:
  remoteshell:
    command: "uvx"
    args: ["remoteshell-mcp"]

在 Hermes TUI 中运行 /reload-mcp 以加载新服务器。

编辑 ~/.openclaw/openclaw.json：

{
  "mcp": {
    "servers": {
      "remoteshell": {
        "command": "uvx",
        "args": ["remoteshell-mcp"]
      }
    }
  }
}

或者运行 openclaw configure 通过交互式向导添加它。

将此添加到你的 MCP 客户端配置中：

{
  "mcpServers": {
    "remoteshell": {
      "command": "uvx",
      "args": ["remoteshell-mcp"]
    }
  }
}

📖 使用

入门很简单！你可以选择：

🤖 让 LLM 为你配置 - 只需告诉 LLM 你的主机、用户名、密码等，并让它设置服务器配置
⚙️ 手动配置 - 直接编辑位于 ~/.config/remoteshell/hosts.json 的配置文件

💾 配置与存储

RemoteShell 将你的服务器配置安全存储在：

~/.config/remoteshell/hosts.json

🔧 配置管理

LLM 管理：LLM 使用 save_server 和 remove_server 工具自动管理此文件
手动编辑：你也可以直接编辑 JSON 文件以进行高级配置

📋 示例配置

{
  "version": 1,
  "servers": {
    "production-server": {
      "host": "1.2.3.4",
      "user": "root",
      "port": 22,
      "auth_type": "password",
      "password": "your_secure_password",
      "last_connected": null
    },
    "staging-server": {
      "host": "staging.example.com",
      "user": "ubuntu",
      "port": 22,
      "auth_type": "private_key",
      "private_key": "~/.ssh/id_rsa",
      "last_connected": "2025-01-01T00:00:00+00:00"
    }
  }
}

🔒 安全说明

在 POSIX 系统上，保护你的配置文件：

chmod 600 ~/.config/remoteshell/hosts.json

🛠️ 可用工具

RemoteShell 提供以下 MCP 工具用于远程服务器管理：

📋 `list_servers()`

用途：显示所有已保存的服务器配置及其连接状态和最后活动时间。

使用时机：

用户要求“连接到服务器”或“显示机器”
未提供特定的 connection_id
需要查看可用的服务器

示例：“显示我已配置了哪些服务器” → 返回所有已保存服务器及其在线状态的列表

💾 `save_server(connection_id, host, user, auth_type, credential, port)`

用途：创建或更新带有身份验证凭据的服务器配置。

参数：

connection_id：服务器的唯一标识符（例如，“production”、“staging”）
host：服务器主机名或 IP 地址
user：SSH 用户名
auth_type："password" 或 "private_key"
credential：
- 对于 password：明文密码字符串
- 对于 private_key：文件路径（例如，~/.ssh/id_rsa）或 PEM 密钥内容
port：SSH 端口（可选；默认为 22，如果省略则保留已保存的端口）

使用时机：

添加新的服务器配置
在身份验证失败后更新凭据
更改服务器连接详情

🗑️ `remove_server(connection_id)`

用途：从存储中永久删除服务器配置。

使用时机：

用户明确要求删除或忘记服务器
服务器不再可访问或不再需要

⚠️ 警告：此操作无法撤销

⚡ `execute_command(connection_id, command)`

用途：远程执行非交互式 shell 命令并返回结果。

返回：stdout、stderr 和 exit_code

使用时机：

运行系统命令、脚本或实用程序
检查服务器状态、磁盘使用情况、进程列表
文件操作、包管理等

不应使用的情况：

交互式程序（vim、htop、top）
需要手动输入的命令（[Y/n] 提示）- 除非使用类似 -y 的标志

示例：execute_command(connection_id="production", command="df -h")

📤 `upload_file(connection_id, local_path, remote_path)`

用途：通过 SFTP 将文件从本地计算机上传到远程服务器。

参数：

local_path：本地计算机上文件的路径
remote_path：远程服务器上的目标路径

说明：

如果 remote_path 是目录，则保留原始文件名
如果省略 local_path，服务器会选择默认路径并在响应中返回

📥 `download_file(connection_id, remote_path, local_path)`

用途：通过 SFTP 将文件从远程服务器下载到本地计算机。

参数：

remote_path：远程服务器上文件的路径
local_path：本地计算机上的目标路径

说明：

如果省略 local_path，默认路径为：~/.config/remoteshell/downloads/<connection_id>/<basename>

🧪 开发

本地开发设置

对于本地开发，请使用此 MCP 配置：

{
  "mcpServers": {
    "remoteshell": {
      "command": "uv",
      "args": ["--directory", "/absolute/path/to/remoteShell-mcp", "run", "remoteshell-mcp"]
    }
  }
}

运行测试

uv run pytest

Available Tools

6 tools

download_fileA

Download a remote file to a local path (on the machine running this MCP server) via SFTP.

When to use: Fetch logs, reports, or backups from the remote. When NOT to use: Avoid very large downloads (>100MB) unless you verified size first.

Example: download_file(connection_id="srv1", remote_path="/var/log/syslog", local_path="./logs/")

Name	Required	Description
`local_path`	No	Local destination path. Defaults to ~/.config/remoteshell/downloads/<connection_id>/
`remote_path`	Yes	Path to the remote file to download
`connection_id`	Yes	Unique identifier of the server connection

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.2/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 mentions SFTP, default local path, and warns about large files. However, it lacks details on overwrite behavior, directory creation, error handling, or authentication requirements, which are important for a file download tool.

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 three sentences and an example, all essential. First sentence states purpose, second gives usage guidelines, third is an example. No wasted words, well-structured.

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?

The tool has 3 parameters with full schema coverage, usage guidelines, and a size warning. An output schema exists, so return values need not be described. However, missing details like overwrite behavior and error handling slightly reduce completeness.

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 baseline is 3. The description adds little beyond schema: it restates default for local_path in prose and provides an example. No additional semantics for connection_id or remote_path.

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 'Download a remote file to a local path via SFTP.' This specifies the action (download), the resource (remote file), and the protocol (SFTP). It distinguishes from sibling tools like upload_file (opposite direction) and execute_command (command execution).

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

Usage Guidelines5/5

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

The description explicitly says 'When to use: Fetch logs, reports, or backups' and 'When NOT to use: Avoid very large downloads (>100MB) unless you verified size first.' This provides clear context and a size limitation, guiding the agent on appropriate usage.

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

execute_commandA

Execute a non-interactive shell command on a remote server and return stdout/stderr/exit_code.

When to use: Status checks (df, ls), file ops (cp, mv), and scripts that do not require live interaction. When NOT to use: Do not run interactive tools (vim, htop, top) or commands that require manual prompts.

Example: execute_command(connection_id="srv1", command="df -h")

Name	Required	Description	Default
`command`	Yes	Shell command to execute (non-interactive only)
`connection_id`	Yes	Unique identifier of the server connection

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations exist, so description must cover behavior. It states non-interactive and returns, but does not explicitly disclose potential for server mutation (e.g., cp, mv modify files). Could be clearer about destructive potential.

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?

Four lines with purpose, usage guidance, and example. Every sentence earns its place, well-structured and front-loaded.

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, return values need not be explained. Covers usage context and parameter roles. Lacks mention of error/timeout handling but adequate.

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% with clear descriptions. The description adds only example and non-interactive context, which is marginal beyond schema. Baseline 3 is appropriate.

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?

Clearly states 'Execute a non-interactive shell command on a remote server and return stdout/stderr/exit_code.' Specific verb and resource, distinguishes from sibling tools like upload_file or remove_server.

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

Usage Guidelines5/5

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

Provides explicit when-to-use (status checks, file ops, scripts) and when-NOT-to-use (interactive tools like vim, htop), plus a concrete example.

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

list_serversA

List all servers saved locally by this MCP server (persistent inventory).

When to use: When the user asks to connect to a server, manage machines, or did not specify a connection_id. When NOT to use: Not needed if you already know the correct connection_id.

Example: "Show me which servers I have."

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

Although no annotations are provided, the description transparently states the tool reads from a 'persistent inventory' and does not indicate destructive behavior. It reasonably covers the safety profile for a read-only list operation.

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?

Extremely concise: two sentences plus structured when/when-not guidelines. Every sentence adds value, and the purpose is front-loaded. No unnecessary words.

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

Completeness5/5

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

Given zero parameters and an output schema that documents return values, the description fully equips the agent: it explains purpose, usage boundaries, and provides an example. No gaps remain.

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?

There are zero parameters; the schema coverage is 100% (no parameters). Per guidelines, baseline for 0 parameters is 4. The description adds no parameter info, but none is needed.

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 explicitly states 'List all servers saved locally by this MCP server (persistent inventory)', using a specific verb and resource. It clearly distinguishes from sibling tools that add, remove, or execute actions.

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

Usage Guidelines5/5

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

Provides explicit 'When to use' and 'When NOT to use' conditions, including an alternative (using a known connection_id) and an example query. This gives clear guidance for the agent.

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

remove_serverA

Permanently delete a saved server profile from the local host store.

When to use: Only when the user explicitly asks to forget/remove a server. When NOT to use: Do not remove servers just because a connection failed.

Example: remove_server(connection_id="srv1")

Name	Required	Description	Default
`connection_id`	Yes	Unique identifier of the server to remove

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. States 'permanently delete' indicating irreversibility. Could mention error handling for missing server, but sufficient for a simple delete.

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?

Short, front-loaded: purpose first, then guidelines, then example. No wasted words.

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

Completeness5/5

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

Simple tool with one param and output schema. Description covers purpose, usage guidelines, and example adequately.

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?

Schema already covers 'connection_id' with description. The example usage adds practical context beyond schema.

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?

States 'Permanently delete a saved server profile' with specific verb and resource. Distinct from siblings like list_servers and execute_command.

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

Usage Guidelines5/5

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

Explicitly says when to use ('only when user asks to forget/remove') and when NOT to use ('not just because connection failed'). Provides clear context and exclusion.

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

save_serverA

Persist (create or update) a server connection profile in the local host store.

When to use: When the user provides new SSH details, or after an auth_failed error to update credentials. When NOT to use: Do not ask for credentials again if they are already saved and still valid.

Example: save_server(connection_id="srv1", host="1.2.3.4", user="root", auth_type="password", credential="", port=2222)

Name	Required	Description
`host`	Yes	Server hostname or IP address
`port`	No	SSH port. Defaults to 22. If omitted, keeps the existing saved port (if any).
`user`	Yes	SSH username
`auth_type`	Yes	Authentication method: 'password' or 'private_key'
`credential`	Yes	Password for 'password' auth, or path/PEM text for 'private_key' auth
`connection_id`	Yes	Unique identifier for this server connection

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.2/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 indicates mutation (create/update) and local persistence, but does not disclose side effects (e.g., whether existing connection_id is overwritten), authentication requirements beyond schema, or rate limits. Adequate but not detailed.

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?

Three sentences plus an example, front-loaded with purpose, then usage context. No fluff; every sentence earns its place.

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 has 6 parameters (5 required) and an output schema (not shown but exists), the description covers usage context well. Could mention the return value (e.g., confirmation of save) but not required since output schema exists. Slightly above adequate.

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 baseline is 3. The description does not add new param semantics beyond the example; the schema already covers each parameter well. No extra value provided.

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 'Persist (create or update) a server connection profile in the local host store', using a specific verb ('persist') and resource ('server connection profile'). It also contrasts with sibling tools like 'remove_server' and 'list_servers' by focusing on creation/update.

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

Usage Guidelines5/5

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

Explicitly states when to use ('new SSH details, or after an auth_failed error to update credentials') and when NOT to use ('Do not ask for credentials again if they are already saved and still valid'). Includes a concrete example.

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

upload_fileA

Upload a local file (on the machine running this MCP server) to a remote server via SFTP.

When to use: Deploy configs, scripts, or artifacts to the remote. When NOT to use: Do not upload huge files blindly; verify size/permissions first.

Example: upload_file(connection_id="srv1", local_path="./config.yaml", remote_path="/etc/app/")

Name	Required	Description
`local_path`	No	Local file path to upload. Defaults to a path in ~/.config/remoteshell/uploads/
`remote_path`	Yes	Destination path on the remote server
`connection_id`	Yes	Unique identifier of the server connection

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, description carries full burden. It mentions SFTP and cautions about large files, but does not specify whether uploads overwrite existing files, preserve timestamps, or handle permissions. Moderate transparency.

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?

Very concise with three short sentences and an example. No fluff. Front-loaded with the core action. Well-structured.

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?

Covers purpose, usage, and example. Output schema exists, so return values are handled. Lacks mention of file overwriting or error conditions, but overall sufficient for a straightforward upload 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%, so baseline is 3. The description adds an example call but no additional semantic detail beyond schema. No bonus or penalty.

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 action: 'Upload a local file...to a remote server via SFTP.' This is a specific verb-resource combination that distinguishes it from siblings like download_file or execute_command.

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

Usage Guidelines5/5

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

Provides explicit 'When to use' (deploy configs, scripts, artifacts) and 'When NOT to use' (avoid blind upload of huge files; verify size/permissions). This offers clear context for decision-making.

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.

6 tool updatesv1.1.1Jul 29, 2026
- First observeddownload_file
- First observedexecute_command
- First observedlist_servers
- First observedremove_server
- First observedsave_server
- First observedupload_file

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

A4.4/5.0

Scored 2026-07-29 06:40 across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: server profile management (save, list, remove) and remote operations (execute, upload, download). No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., remove_server, list_servers, execute_command), making them predictable and easy to use.

Tool Count5/5

6 tools is well-scoped for a remote shell MCP, covering server management and core file/command operations without superfluous tools.

Completeness4/5

Covers key CRUD operations for servers and essential remote actions (execute, upload, download). Minor gap: no explicit test-connection or update server operation, but save_server handles updates.

Maintenance

ActivitySlowing

ResponsivenessUnresponsive

Resources

Related MCP Connectors

SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
215
https://mcp.sentinelx.app/mcp/mcp
emisarOAuth
dev.emisar
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Cloud Platforms Security Networking & Infrastructure
2331
https://emisar.dev/api/mcp/rpc
browser-ssh
com.browserssh
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Shell Access File Systems
2
https://api.browserssh.com/mcp
Remote MCP A
com.remote-mcp.mcp
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.
Developer Tools Search Agent Orchestration
13
https://mcp.remote-mcp.com

Related MCP Servers

SSH MCP Server
Shell Access Code Execution
vilasone455
F
license
A
quality
D
maintenance
A local Model Context Protocol server that allows LLMs to securely execute shell commands on remote Linux and Windows systems via SSH connections.
Updated a year ago (2025-05-27 06:59 UTC)
6
5 npm
2
-
ssh-client-mcp-server
Shell Access Command Line
jordanburke
A
license
Not graded
quality
B
maintenance
A local MCP server that enables LLMs to execute shell commands on remote hosts over SSH with multiple authentication methods.
Updated 6 days ago (2026-10-19 23:55 UTC)
35 npm
3
MIT
MCP SSH Server
Shell Access Command Line
Maxim11111
A
license
Not graded
quality
D
maintenance
A centralized MCP server that enables LLM agents to securely execute commands and manage Linux servers via SSH.
Updated 6 months ago (2026-04-12 21:24 UTC)
2
MIT
SSH MCP Server
Shell Access Command Line
aaronckj
A
license
Not graded
quality
D
maintenance
A local MCP server that enables LLMs to execute shell commands on remote Linux and Windows systems via SSH with configurable timeout and authentication options.
Updated 3 months ago (2026-07-28 05:51 UTC)
4,775 npm
MIT

🔗 RemoteShell MCP

✨ 功能

🚀 安装

📖 使用

💾 配置与存储

🔧 配置管理

📋 示例配置

🔒 安全说明

🛠️ 可用工具

📋 list_servers()

💾 save_server(connection_id, host, user, auth_type, credential, port)

🗑️ remove_server(connection_id)

⚡ execute_command(connection_id, command)

📤 upload_file(connection_id, local_path, remote_path)

📥 download_file(connection_id, remote_path, local_path)

🧪 开发

本地开发设置

运行测试

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

📋 `list_servers()`

💾 `save_server(connection_id, host, user, auth_type, credential, port)`

🗑️ `remove_server(connection_id)`

⚡ `execute_command(connection_id, command)`

📤 `upload_file(connection_id, local_path, remote_path)`

📥 `download_file(connection_id, remote_path, local_path)`