Remotify MCP vs SSH MCP Server
A side-by-side look at the Remotify MCP and SSH MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Remotify MCP for command line work as a local process; choose SSH MCP Server for command line as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Remotify MCP when
- You need dedicated capabilities in the Command Line domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
DOMAIN, SCHEME, PUBLIC_PORT, NGINX_MODE, SESSION_TTL, LONGPOLL_MS, MAX_BODY_SIZE, CERTBOT_EMAIL. - You want tools like
remote_exec, remote_session_info, remote_session_reset.
Choose SSH MCP Server when
- You need dedicated capabilities in the Command Line domain.
- You prefer a local stdio subprocess transport.
- You want tools like
ssh_exec, ssh_read_file, ssh_write_file.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Command Line | Command Line |
| Quality signal | 65/100 · Great | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Free | Not declared |
| Required env vars | DOMAINSCHEMEPUBLIC_PORTNGINX_MODESESSION_TTLLONGPOLL_MSMAX_BODY_SIZECERTBOT_EMAIL | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 3 | 6 |
| Directory activity | 4 views 0 installs 0 upvotes | 4 views 0 installs 0 upvotes |
| Tools | 3 | 21 |
| Full listing | View Remotify MCP | View SSH MCP Server |
Tools & capabilities
Remotify MCP tools 3
remote_execExecute a shell command on the PROJECT'S REMOTE SERVER via the remotify relay (the deployed/production/staging box, NOT the developer's local machine). Examples: 'check disk usage', 'restart the service', 'tail the app log', 'query the prod DB', 'is port 443 open in prod', 'what version is running in staging'. Chain this tool freely for iterative work - log analysis with grep/awk/sed/head/tail, narrowing a search, cross-checking outputs, diagnosing slow services with ps/vmstat/netstat/iostat. Each call saves a manual copy-paste roundtrip; only surface the meaningful result or synthesis to the user. In supervised mode the operator approves each command on the remote via y/N prompt, so no extra confirmation is needed from the assistant. Returns combined stdout+stderr as plain text on success. HARD RULE: the user connects the remote by pasting a listener one-liner; that is the ONLY execution path. NEVER fall back to ssh, scp, or any other transport, and NEVER try to start the listener yourself. The user chose remotify precisely so that no agent gets shell access. Pending handling: the response text may start with one of these markers. '[pending]' WITH paste one-liners = no remote listener is connected; nothing can run until the user pastes one. STOP: end your turn immediately with a short message that shows BOTH one-liners (supervised and auto) verbatim in a fenced code block. Do not call any tool after that message: hosts collapse text written between tool calls, so the one-liners only reach the user as the final message of the turn. The command stays queued; when the user replies that the listener is running, call remote_exec again with the EXACT SAME arguments to collect the output. It will not execute twice. '[pending]' WITHOUT one-liners = the listener is online but the relay cannot confirm pickup yet. Call remote_exec again with the EXACT SAME arguments; loop silently, do not ask the user anything, and give up only after about 10 consecutive [pending] responses. '[in-flight]' = the command IS already being executed on the remote (cmd was picked up, no output yet). In that case: 1. Do NOT give up. Long operations (mongodump, restic, rsync, big installs, slow restarts) routinely take many minutes. 2. Call remote_exec again with the EXACT SAME arguments; the relay will return the output the moment the command finishes. 3. Do NOT tell the user the listener disconnected; do NOT ask them to re-paste the listener; do NOT switch to a different command. 4. There is no LLM-side retry cap on '[in-flight]'; keep waiting until the result lands or the relay returns something else. '[busy]' = you tried to issue a NEW command while a previous one is still executing on the remote. Each session is single-flight (one command at a time). In that case: 1. If you know the previous command, call remote_exec with ITS exact arguments first to drain its result, then issue the new one. 2. If you do NOT know it (e.g. it was issued by an earlier session), keep calling remote_exec with the NEW command's arguments: stale state left by a dead session is cleared automatically (see '[recovered]'). 3. If the [busy] response contains paste one-liners, the listener is disconnected and the wedge can ONLY clear once the user reconnects it: end your turn with BOTH one-liners verbatim, exactly as for a no-listener [pending]. '[recovered]' = wedged state left by a dead session/listener was cleared automatically. Read the rest of the message: either the command already proceeded, or you are asked to call remote_exec again with the EXACT SAME arguments. '[resumed]' = the returned output was already waiting on the relay and belongs to the most recent run (e.g. you re-issued a command after an interruption). Use it if it matches what you expected; if not, issue the command again. '[unknown-result]' = the session expired while the command was already running on the remote. Its output was lost and it may or may not have completed. A new session was minted; end your turn with BOTH reconnect one-liners verbatim, then decide whether re-running is safe once the user is back. The server will NOT silently re-run it. '[session-renewed]' = the session key changed; the one-liners that follow are for the NEW key. Treat it like a no-listener [pending]: end your turn with both lines verbatim.remote_session_infoReturn the current relay session: key, URLs, and the exact one-liners to paste on the remote machine to start the listener (remote_quickstart = supervised, y/N per command; remote_quickstart_auto = unattended). When you show them to the user, show BOTH verbatim in a fenced code block and make them the final message of your turn.remote_session_resetRecover a wedged remotify session. Default (no arguments): clear stuck relay state in place - drops any queued command/result and the in-flight marker; the session key and a connected listener keep working. With {"rotate": true}: abandon the current session and mint a brand-new key - the old key dies, the remote listener disconnects, and the user must paste the NEW runner one-liner (returned by this tool) on the remote. Normally NOT needed: remote_exec auto-recovers from stale state by itself. Use it only when remote_exec stays wedged (repeated [busy] for a command you never issued) despite same-args retries, or when the user explicitly asks to reset or rotate the session.
SSH MCP Server tools 21
ssh_execExecute a command on a remote host via SSH. The command is interpreted by the remote login shell — pipes, redirects, globs, and other shell metacharacters work as expected. Returns up to three content blocks in this order: the status (`[exit code: N]`, plus the signal and any truncation), then `[stderr]`, then `[stdout]`. Status comes first so a proxy that cuts long results (Yaw MCP keeps about 100 KB) never drops the exit code; for big output, filter or page on the remote (head, tail, grep). Use `env` to set environment variables for this call without modifying the command string. Subject to SSH_MCP_COMMAND_WHITELIST / SSH_MCP_COMMAND_BLACKLIST if configured (policy is checked against the env-prefixed command).ssh_read_fileRead a file from a remote host via SFTP. A whole-file read is limited to 10 MB. For a large file -- or behind a proxy that caps results, such as Yaw MCP at about 100 KB -- read it in pages with `offset` and `length` (bytes): a paged read returns a status block first (`[bytes A-B of SIZE]` and the next offset) and then the text. If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting.ssh_write_fileWrite content to a file on a remote host via SFTP. Creates or overwrites the file. If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting. NOT gated by SSH_MCP_COMMAND_WHITELIST / SSH_MCP_COMMAND_BLACKLIST: command policy applies only to ssh_exec and ssh_multi_exec, so a blacklist such as `^rm` does NOT block this tool.ssh_uploadUpload a local file to a remote host via SFTP. Reads an arbitrary local file at an agent-chosen `localPath` -- any file readable by this process leaves the machine toward the remote host (the mirror direction of ssh_download's local write). If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting. NOT gated by SSH_MCP_COMMAND_WHITELIST / SSH_MCP_COMMAND_BLACKLIST: command policy applies only to ssh_exec and ssh_multi_exec, so a blacklist such as `^rm` does NOT block this tool.ssh_downloadDownload a file from a remote host to local filesystem via SFTP. If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting.ssh_lsList files in a directory on a remote host via SFTP. If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting.ssh_statGet metadata for a file or directory on a remote host via SFTP. Returns size, permissions (octal), uid/gid, mtime/atime, and the path type. Symlinks are reported as `symlink -> <target kind>`: the type describes the link itself while size/mode/mtime describe its TARGET, and a dangling symlink is reported rather than erroring. Use this instead of parsing `ls -la` output. If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting.ssh_mkdirCreate a directory on a remote host via SFTP. Set `recursive: true` to create parent directories as needed (like `mkdir -p`). Existing intermediate dirs are tolerated; an existing leaf path is still an error. Unlike the other SFTP tools, the path may be relative. If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting. NOT gated by SSH_MCP_COMMAND_WHITELIST / SSH_MCP_COMMAND_BLACKLIST: command policy applies only to ssh_exec and ssh_multi_exec, so a blacklist such as `^rm` does NOT block this tool.ssh_deleteDelete a file or empty directory on a remote host via SFTP. Auto-detects the path type and calls the right SFTP op (unlink for files/symlinks, rmdir for empty dirs). Recursive directory delete is intentionally NOT supported -- for that, use ssh_exec with `rm -rf` explicitly so the destructive intent is visible in the tool trace. If the connection pool is full (SSH_MCP_MAX_POOL_SIZE, default 100), waits up to 30s for a free slot before starting. NOT gated by SSH_MCP_COMMAND_WHITELIST / SSH_MCP_COMMAND_BLACKLIST: command policy applies only to ssh_exec and ssh_multi_exec, so a blacklist such as `^rm` does NOT block this tool.ssh_diagnoseDiagnose SSH connectivity issues. Checks ssh-agent status, loaded keys, known_hosts, SSH config, and attempts a test connection. Use this BEFORE attempting SSH operations if you suspect connectivity issues, or AFTER a failed SSH operation to understand why it failed.ssh_agent_ensureEnsure ssh-agent is running and reachable. Starts a new agent if needed and sets environment variables so subsequent SSH operations work. Use this FIRST when SSH operations fail with agent-related errors.ssh_key_listList all SSH private keys in ~/.ssh/ with their type, fingerprint, and whether they are loaded in the agent. Use this to find which keys are available and which ones need to be loaded. Reports isError only when ~/.ssh exists but could not be read -- an absent or empty ~/.ssh is a successful answer with a ssh-keygen hint.- +9 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Remotify MCP
{
"mcpServers": {
"remotify-mcp": {
"command": "npx",
"args": [
"-y",
"remotify-mcp@latest"
],
"env": {
"DOMAIN": "YOUR_DOMAIN_HERE",
"SCHEME": "YOUR_SCHEME_HERE",
"PUBLIC_PORT": "YOUR_PUBLIC_PORT_HERE",
"NGINX_MODE": "YOUR_NGINX_MODE_HERE",
"SESSION_TTL": "YOUR_SESSION_TTL_HERE",
"LONGPOLL_MS": "YOUR_LONGPOLL_MS_HERE",
"MAX_BODY_SIZE": "YOUR_MAX_BODY_SIZE_HERE",
"CERTBOT_EMAIL": "YOUR_CERTBOT_EMAIL_HERE"
}
}
}
}
SSH MCP Server
{
"mcpServers": {
"ssh-mcp-server-2": {
"command": "npx",
"args": [
"-y",
"@yawlabs/ssh-mcp"
]
}
}
}
Frequently asked questions
Remotify MCP is categorized under Command Line and uses a local stdio subprocess. SSH MCP Server belongs to Command Line and uses a local stdio subprocess. Pick Remotify MCP for command line work and SSH MCP Server for command line.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Remotify MCP is listed as free. SSH MCP Server has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add remotify-mcp and ssh-mcp-server-2 as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Remotify MCP has a quality signal of 65/100 (Great) with 4 views, 0 installs and 3 GitHub stars. SSH MCP Server has 64/100 (Good) with 4 views, 0 installs and 6 GitHub stars.