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

A Model Context Protocol (MCP) server that enables LLMs to securely manage and execute commands on remote SSH servers.

✨ Características

🔐 Gestión segura de credenciales - Guardar los perfiles de servidor SSH una vez, sin necesidad de volver a escribir las credenciales
💻 Ejecución remota de comandos - Ejecutar comandos de shell no interactivos de forma remota
📁 Operaciones de archivos - Subir/descargar archivos mediante SFTP
🤖 Impulsado por LLM - Construido con FastMCP y Paramiko

Related MCP server: ssh-client-mcp-server

🚀 Instalación

RemoteShell es un servidor MCP stdio distribuido en PyPI. Ejecútalo directamente con uvx — no se requiere ningún paso de instalación. Luego registra el servidor con tu agente de codificación de IA:

Claude Code

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

Codex

codex mcp add remoteshell -- uvx remoteshell-mcp

Otros agentes — haz clic en el tuyo para expandir 👇

cursor mcp add remoteshell -- uvx remoteshell-mcp

Edita ~/.gemini/config/mcp_config.json (global) o .agents/mcp_config.json (proyecto):

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

O abre la vista MCP Servers en la TUI de Antigravity y ejecuta el comando /mcp.

opencode mcp add

Elige local y luego introduce uvx remoteshell-mcp.

Edita ~/.hermes/config.yaml:

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

Ejecuta /reload-mcp en la TUI de Hermes para que el nuevo servidor se cargue.

Edita ~/.openclaw/openclaw.json:

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

O ejecuta openclaw configure para añadirlo mediante el asistente interactivo.

Añade esto a la configuración de tu cliente MCP:

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

📖 Uso

¡Empezar es fácil! Puedes:

🤖 Deja que el LLM configure por ti - Simplemente indica al LLM tu host, nombre de usuario, contraseña, etc., y pídele que configure el servidor
⚙️ Configuración manual - Edita directamente el archivo de configuración en ~/.config/remoteshell/hosts.json

💾 Configuración y almacenamiento

RemoteShell almacena de forma segura tus configuraciones de servidor en:

~/.config/remoteshell/hosts.json

🔧 Gestión de configuración

Gestionado por LLM: El LLM gestiona automáticamente este archivo usando las herramientas save_server y remove_server
Edición manual: También puedes editar directamente el archivo JSON para configuraciones avanzadas

📋 Ejemplo de configuración

{
  "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"
    }
  }
}

🔒 Nota de seguridad

En sistemas POSIX, protege tu archivo de configuración:

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

🛠️ Herramientas disponibles

RemoteShell proporciona las siguientes herramientas MCP para la gestión de servidores remotos:

📋 `list_servers()`

Propósito: Muestra todos los perfiles de servidor guardados con su estado de conexión y última actividad.

Cuándo usarla:

El usuario pide "conectar al servidor" o "mostrar máquinas"
No se proporciona un connection_id específico
Se necesita ver los servidores disponibles

Ejemplo: "Muéstrame qué servidores tengo configurados" → Devuelve una lista de todos los servidores guardados con su estado en línea

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

Propósito: Crea o actualiza un perfil de servidor con credenciales de autenticación.

Parámetros:

connection_id: Identificador único del servidor (p. ej., "production", "staging")
host: Nombre de host o dirección IP del servidor
user: Nombre de usuario SSH
auth_type: "password" o "private_key"
credential:
- Para password: Cadena de contraseña en texto plano
- Para private_key: Ruta del archivo (p. ej., ~/.ssh/id_rsa) o contenido de la clave PEM
port: Puerto SSH (opcional; por defecto es 22 y conserva el puerto guardado existente si se omite)

Cuándo usarla:

Añadir una nueva configuración de servidor
Actualizar credenciales tras un fallo de autenticación
Cambiar los detalles de conexión del servidor

🗑️ `remove_server(connection_id)`

Propósito: Elimina permanentemente un perfil de servidor del almacenamiento.

Cuándo usarla:

El usuario solicita explícitamente eliminar u olvidar un servidor
El servidor ya no es accesible o necesario

⚠️ Advertencia: Esta acción no se puede deshacer

⚡ `execute_command(connection_id, command)`

Propósito: Ejecuta comandos de shell no interactivos de forma remota y devuelve los resultados.

Devuelve: stdout, stderr y exit_code

Cuándo usarla:

Ejecutar comandos del sistema, scripts o utilidades
Comprobar el estado del servidor, uso de disco, listas de procesos
Operaciones de archivos, gestión de paquetes, etc.

Cuándo NO usarla:

Programas interactivos (vim, htop, top)
Comandos que requieren entrada manual (prompts [Y/n]) - a menos que se usen banderas como -y

Ejemplo: execute_command(connection_id="production", command="df -h")

📤 `upload_file(connection_id, local_path, remote_path)`

Propósito: Sube archivos desde tu máquina local a un servidor remoto mediante SFTP.

Parámetros:

local_path: Ruta del archivo en tu máquina local
remote_path: Ruta de destino en el servidor remoto

Notas:

Si remote_path es un directorio, se conserva el nombre de archivo original
Si se omite local_path, el servidor selecciona una ruta predeterminada y la devuelve en la respuesta

📥 `download_file(connection_id, remote_path, local_path)`

Propósito: Descarga archivos desde un servidor remoto a tu máquina local mediante SFTP.

Parámetros:

remote_path: Ruta del archivo en el servidor remoto
local_path: Ruta de destino en tu máquina local

Notas:

Si se omite local_path, el valor predeterminado es: ~/.config/remoteshell/downloads/<connection_id>/<basename>

🧪 Desarrollo

Configuración de desarrollo local

Para el desarrollo local, usa esta configuración de MCP:

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

Ejecutar pruebas

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/")

ParametersJSON Schema

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

ParametersJSON 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")

ParametersJSON Schema

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

Output Schema

ParametersJSON 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."

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON 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")

ParametersJSON Schema

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

Output Schema

ParametersJSON 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)

ParametersJSON Schema

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

ParametersJSON 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/")

ParametersJSON Schema

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

ParametersJSON 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

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

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
emisarOAuth
dev.emisar
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Cloud Platforms Security Networking & Infrastructure
2331
browser-ssh
com.browserssh
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Shell Access File Systems
2
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

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 3 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)
3,891 npm
MIT

🔗 RemoteShell MCP

✨ Características

🚀 Instalación

📖 Uso

💾 Configuración y almacenamiento

🔧 Gestión de configuración

📋 Ejemplo de configuración

🔒 Nota de seguridad

🛠️ Herramientas disponibles

📋 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)

🧪 Desarrollo

Configuración de desarrollo local

Ejecutar pruebas

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)`