Which integrations are available for this server?

Allows Hermes and other MCP-capable extensions to execute SSH commands, manage files via SFTP, and run commands on remote servers through the MCP protocol. Allows OpenAI Codex CLI to execute SSH commands, manage files via SFTP, and run commands on remote servers through the MCP protocol.

How do I use ssh-chat-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ssh-chat-mcp SSH into 192.168.1.100 as root and run uptime" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ssh-chat-mcp

by aiplatforms-ru

Overview Schema Related Servers Score Discussions

TypeScript

Remote

English

ssh-chat-mcp is a Model Context Protocol server that lets an LLM client open temporary SSH/SFTP sessions to remote hosts, run commands (including sudo -iu), and upload/download files — without the MCP server holding any pre-baked credentials, hosts, paths, or environment secrets.

You start the server with no arguments. Then, in chat, you give the model a host plus credentials, it calls connect, does its work, calls disconnect, and the credentials are wiped from RAM.

Built by AI Platforms — on-premises LLM and computer-vision systems for enterprises that need their AI to stay inside their own server room.

Why zero-config

Most SSH automation wants you to put ~/.ssh/config, inventory.yml, HOST=…, SSH_PRIVATE_KEY=… or similar on disk. That's fine for one stable production target and a CI worker. It's wrong when:

You want an LLM client to occasionally SSH into a box you set up yesterday, deploy a thing, and walk away.
You don't want a hostname / username / key visible to anything that reads your MCP config — including extensions, IDE integrations, or other MCP servers.
You don't want the LLM client to remember anything about your infrastructure once the chat ends.

ssh-chat-mcp keeps the MCP layer pure and pushes every connection detail into the conversation, where you (the user) can see it explicitly and where it dies with the connection.

Install

Requires Node.js 20 or newer (22 recommended).

Option A — npx (recommended, zero install). Point your MCP client at npx -y ssh-chat-mcp. The first run downloads the package; later runs are instant from cache. Nothing to clone or build. See Integrations.

# verify it runs (starts silently; Ctrl+C to stop)
npx -y ssh-chat-mcp

Option B — global install.

npm install -g ssh-chat-mcp
ssh-chat-mcp        # starts the stdio server

Option C — from source (for development).

git clone https://github.com/aiplatforms-ru/ssh-chat-mcp.git
cd ssh-chat-mcp
npm install
npm run build
node build/index.js

In all cases the server starts silently and must not print anything to stdout (stdout is reserved for MCP JSON-RPC traffic). Press Ctrl+C twice quickly to stop. A single Ctrl+C only cancels in-flight commands/jobs so MCP clients can interrupt a tool call without killing the whole stdio transport. No output is expected during normal operation.

Quick start

In your MCP client (Claude Code / Codex / Kilo / LM Studio / Cursor / etc.), register the server (see Integrations below), then say:

Use the ssh-chat MCP. Call connect with connectionName=t1, host=203.0.113.10, username=deploy, password=<your password>. Then run exec with command whoami && hostname. Then disconnect.

That's the whole workflow: connect → do stuff → disconnect.

Tools

All inputs are validated with zod. All outputs and error messages pass through a redaction layer that removes:

Field values for keys named password, passphrase, privateKey, sudoPassword, token, apiKey, Authorization, secret.
password=, *_PASSWORD=, token=, secret=, Authorization: Bearer … patterns in text.
PEM-encoded private key blocks.

Tool	What it does
`connect`	Open an SSH session. Requires `connectionName`, `host`, `username`, plus `password` or `privateKey` (PEM). Optional `port` (default 22), `passphrase`, `readyTimeoutMs`, `keepaliveIntervalMs`. Credentials live only in RAM.
`disconnect`	Close the SSH+SFTP session and wipe credentials from memory.
`list_connections`	Return non-sensitive metadata for all active connections.
`diagnose`	Local MCP/SSH diagnostics. With no args it proves the MCP server is alive and lists connections/jobs. With `connectionName`, it runs a short SSH probe and returns `ok`, `ssh_unresponsive`, `ssh_error`, `connection_missing`, etc.
`exec`	Run a shell command. With `cwd`, wraps as `cd <quoted cwd> && <command>`. Returns `stdout, stderr, exitCode, signal, timedOut`.
`exec_start`	Start a long-running command and return immediately with `jobId`. Use for `git clone`, `pip install`, `apt install`, builds, and reboot waits that may outlive the MCP client's tool timeout.
`exec_as`	Run as another Linux user via `sudo -S -p '' -iu <runAs> -- bash -lc <command>`. `runAs` is strictly validated (`^[a-z_][a-z0-9_-]{0,31}$`). `sudoPassword` is piped via stdin and never logged.
`exec_as_start`	Long-running version of `exec_as`; returns `jobId` immediately and stores rolling stdout/stderr buffers in memory.
`exec_status`	Read a command job status plus stdout/stderr slices. Pass returned `nextOffset` values back as `stdoutOffset`/`stderrOffset` for incremental log reads.
`exec_jobs`	List known command jobs without logs.
`exec_cancel`	Best-effort cancellation for a job. If the remote PID is known, sends the signal to the remote process group and closes the SSH channel.
`exec_remove`	Remove a completed/cancelled/failed job and drop its buffered logs.
`upload_file`	SFTP upload one file. Optional `mode`, `mkdirParents`.
`upload_directory`	Recursive SFTP upload. Caller-supplied `exclude` list. Symlinks not followed by default.
`download_file`	SFTP download to local disk.
`read_remote_file`	Read remote file as UTF-8 text, up to `maxBytes`. Content is redacted.
`write_remote_file`	Write text to a remote file via SFTP. Useful for staging systemd/nginx configs into `/tmp` and then `sudo mv`-ing them in place.

Long-running commands

For commands that can exceed your MCP client's tool timeout, prefer:

exec_start or exec_as_start with the long command.
exec_status every so often, using stdout.nextOffset and stderr.nextOffset from the previous response.
exec_cancel if the job must be stopped.
exec_remove after completion if you want to drop the in-memory log buffers.

This keeps the MCP transport responsive: the first call only opens the SSH channel and returns a jobId; stdout/stderr are held in rolling in-memory buffers and read later by job id. If a job times out or is cancelled, the server tries to signal the remote process group before closing the SSH channel.

Integrations

All snippets below use the npx form (npx -y ssh-chat-mcp) — no install, no paths. If you installed from source instead, replace { "command": "npx", "args": ["-y", "ssh-chat-mcp"] } with { "command": "node", "args": ["/abs/path/to/ssh-chat-mcp/build/index.js"] }. On Windows, npx-based clients sometimes need the launcher wrapped as "command": "cmd", "args": ["/c", "npx", "-y", "ssh-chat-mcp"].

Claude Code (CLI)

claude mcp add ssh-chat --scope user -- npx -y ssh-chat-mcp

Verify with /mcp inside Claude Code.

Claude Desktop

Edit:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "ssh-chat": {
      "command": "npx",
      "args": ["-y", "ssh-chat-mcp"]
    }
  }
}

Fully restart the Claude Desktop app (quit from tray, not just close the window).

OpenAI Codex CLI

Edit ~/.codex/config.toml (Windows: %USERPROFILE%\.codex\config.toml):

[mcp_servers.ssh-chat]
command = 'npx'
args = ['-y', 'ssh-chat-mcp']
startup_timeout_sec = 30
tool_timeout_sec = 120
enabled = true

Kilo Code

Edit ~/.config/kilo/kilo.jsonc:

{
  "mcp": {
    "ssh-chat": {
      "type": "local",
      "command": ["npx", "-y", "ssh-chat-mcp"],
      "enabled": true,
      "timeout": 120000
    }
  }
}

LM Studio

Edit %USERPROFILE%\.lmstudio\mcp.json (Windows) or the equivalent on your OS:

{
  "mcpServers": {
    "ssh-chat": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "ssh-chat-mcp"]
    }
  }
}

macOS / Linux:

{
  "mcpServers": {
    "ssh-chat": {
      "command": "npx",
      "args": ["-y", "ssh-chat-mcp"]
    }
  }
}

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "ssh-chat": {
      "command": "npx",
      "args": ["-y", "ssh-chat-mcp"]
    }
  }
}

Continue.dev / Hermes / VS Code MCP extensions

Most MCP-capable extensions follow the same shape:

{
  "name": "ssh-chat",
  "command": "npx",
  "args": ["-y", "ssh-chat-mcp"],
  "transport": "stdio"
}

Consult your client's docs for where this JSON lives.

Any stdio-capable MCP client

If your client supports stdio servers at all, point it at:

command: npx
args: ["-y", "ssh-chat-mcp"]
env / cwd: not needed
transport: stdio

There is intentionally nothing else to configure.

Example chat workflow

Use the ssh-chat MCP. Connect to 203.0.113.10:22 as deploy with the password I just gave you. Upload D:\Projects\myapp to /tmp/myapp, excluding .git and node_modules. As appuser, create a venv and install requirements.txt. Write a systemd unit to /tmp/myapp.service and sudo mv it to /etc/systemd/system/. Reload systemd, enable and start myapp.service. Write an nginx site to /tmp/myapp.nginx and install it to /etc/nginx/sites-available/, symlink it into sites-enabled/, run nginx -t, reload nginx. Then disconnect.

Typical tool sequence:

connect — credentials enter memory.
upload_directory — SFTP the project to /tmp/myapp.
exec — cd /tmp/myapp && ... for unprivileged setup.
exec_as — runAs: "appuser" for app-user steps (venv, pip).
write_remote_file — stage /tmp/myapp.service.
exec — sudo mv /tmp/myapp.service /etc/systemd/system/ && sudo systemctl daemon-reload && sudo systemctl enable --now myapp.
exec — sudo nginx -t && sudo systemctl reload nginx.
disconnect — credentials wiped.

Security

See SECURITY.md for the full threat model. Short version:

✅ Credentials never touch disk.
✅ Tool output and error messages pass through redaction.
✅ sudo password is piped via stdin, never on a command line.
✅ POSIX shell quoting on every cwd/command interpolation.
✅ Strict Linux-username validation on runAs.
⚠️ Host-key checking is off by design (zero-config means no on-disk known_hosts). The calling user is responsible for trusting the host.
⚠️ There is no destructive-command blacklist. Your MCP client's tool approval flow is the only checkpoint.
⚠️ Passing a password or private key into chat means it's visible in your chat client's transcript and may be logged by your model provider. Prefer local/private clients (LM Studio, Claude Code locally), and rotate credentials after the session if you have any doubt.

Development

npm install
npm run typecheck
npm test
npm run build

Project layout:

src/
  index.ts                  MCP stdio server + tool registration
  types.ts                  shared types
  ssh/
    connectionManager.ts    in-memory Map<name, descriptor>
    exec.ts                 exec, exec_as (sudo -iu)
    sftp.ts                 upload/download/read/write
  security/
    redact.ts               redact strings, values, errors
    shellQuote.ts           POSIX quoting, Linux-username validation
test/
  redact.test.ts
  shellQuote.test.ts
  errors.test.ts

Related MCP server: ssh-mcp

Русский

ssh-chat-mcp — это MCP-сервер, который позволяет LLM-клиенту открывать временные SSH/SFTP-сессии к удалённым хостам, выполнять команды (включая sudo -iu), загружать и скачивать файлы — без каких-либо предзаписанных в конфиге кредов, хостов, путей и переменных окружения.

Сервер запускается без аргументов. Дальше в чате модель получает от тебя host и креды, вызывает connect, делает работу, вызывает disconnect — и креды стираются из памяти.

Сделано в AI Platforms — внедрение приватных LLM и систем компьютерного зрения для предприятий, которым нужно, чтобы ИИ оставался в их собственной серверной.

Зачем zero-config

Большинство SSH-автоматизаций просит положить на диск ~/.ssh/config, inventory.yml, переменные HOST=…, SSH_PRIVATE_KEY=…. Это нормально для одной стабильной прод-машины и CI-раннера. Это неправильно, когда:

Ты хочешь, чтобы LLM-клиент иногда зашёл по SSH на машину, которую ты поднял вчера, что-то задеплоил и забыл.
Ты не хочешь, чтобы hostname / username / ключ были видны всему, что читает твой MCP-конфиг — расширениям IDE, интеграциям, другим MCP-серверам.
Ты не хочешь, чтобы LLM-клиент вообще что-либо помнил про твою инфраструктуру после окончания чата.

ssh-chat-mcp держит MCP-слой чистым и пушит все детали подключения в переписку, где они видны тебе явно и умирают вместе с соединением.

Установка

Требуется Node.js 20+ (рекомендуется 22).

Вариант A — npx (рекомендуется, без установки). Укажи MCP-клиенту npx -y ssh-chat-mcp. Первый запуск скачает пакет, дальше — мгновенно из кэша. Ничего клонировать и собирать не нужно. См. Интеграции.

# проверка запуска (стартует молча; Ctrl+C для остановки)
npx -y ssh-chat-mcp

Вариант B — глобальная установка.

npm install -g ssh-chat-mcp
ssh-chat-mcp        # запускает stdio-сервер

Вариант C — из исходников (для разработки).

git clone https://github.com/aiplatforms-ru/ssh-chat-mcp.git
cd ssh-chat-mcp
npm install
npm run build
node build/index.js

Во всех случаях сервер запускается молча и не должен ничего писать в stdout (stdout зарезервирован под MCP JSON-RPC). Для остановки нажми Ctrl+C два раза быстро. Один Ctrl+C только отменяет активные команды/jobs, чтобы MCP-клиенты могли прервать tool call без убийства всего stdio-транспорта. В штатной работе вывода быть не должно.

Быстрый старт

В твоём MCP-клиенте (Claude Code / Codex / Kilo / LM Studio / Cursor / …) зарегистрируй сервер (см. Интеграции) и скажи в чате:

Используй MCP ssh-chat. Вызови connect с connectionName=t1, host=203.0.113.10, username=deploy, password=<твой пароль>. Потом запусти exec с command=whoami && hostname. Потом disconnect.

Весь цикл: connect → работа → disconnect.

Инструменты

Все входы валидируются через zod. Все выходы и ошибки проходят через redaction-слой, который убирает:

Значения полей с именами password, passphrase, privateKey, sudoPassword, token, apiKey, Authorization, secret.
Паттерны password=, *_PASSWORD=, token=, secret=, Authorization: Bearer … в тексте.
PEM-блоки приватных ключей.

Инструмент	Что делает
`connect`	Открывает SSH. Обязательно: `connectionName`, `host`, `username` + `password` или `privateKey` (PEM). Опционально: `port` (по умолчанию 22), `passphrase`, `readyTimeoutMs`, `keepaliveIntervalMs`. Креды только в RAM.
`disconnect`	Закрывает SSH+SFTP, стирает креды из памяти.
`list_connections`	Возвращает нечувствительные метаданные активных соединений.
`diagnose`	Локальная диагностика MCP/SSH. Без аргументов доказывает, что MCP-сервер жив, и показывает соединения/jobs. С `connectionName` делает короткий SSH probe и возвращает `ok`, `ssh_unresponsive`, `ssh_error`, `connection_missing` и т.п.
`exec`	Выполняет shell-команду. Если задан `cwd`, оборачивает в `cd <quoted cwd> && <command>`. Возвращает `stdout, stderr, exitCode, signal, timedOut`.
`exec_start`	Запускает долгую команду и сразу возвращает `jobId`. Для `git clone`, `pip install`, `apt install`, сборок, ожидания reboot и всего, что может пережить timeout MCP-клиента.
`exec_as`	Запуск как другой Linux-пользователь через `sudo -S -p '' -iu <runAs> -- bash -lc <command>`. `runAs` строго валидируется (`^[a-z_][a-z0-9_-]{0,31}$`). `sudoPassword` идёт через stdin и никогда не логируется.
`exec_as_start`	Долгая версия `exec_as`: сразу возвращает `jobId` и хранит rolling stdout/stderr buffers в памяти.
`exec_status`	Читает статус job и срезы stdout/stderr. Передавай возвращённые `nextOffset` как `stdoutOffset`/`stderrOffset` для инкрементального чтения логов.
`exec_jobs`	Показывает известные jobs без логов.
`exec_cancel`	Best-effort отмена job. Если известен remote PID, сигнал отправляется remote process group, затем закрывается SSH channel.
`exec_remove`	Удаляет завершённую/отменённую/упавшую job и очищает буферы логов.
`upload_file`	SFTP-загрузка одного файла. Опционально `mode`, `mkdirParents`.
`upload_directory`	Рекурсивная SFTP-загрузка. `exclude` задаёт вызывающий. Симлинки по умолчанию не следуются.
`download_file`	SFTP-скачивание на локальный диск.
`read_remote_file`	Чтение удалённого файла как UTF-8, до `maxBytes`. Контент редактируется.
`write_remote_file`	Запись текста на удалённый файл через SFTP. Полезно для staging systemd/nginx-конфигов в `/tmp` с последующим `sudo mv`.

Долгие команды

Для команд, которые могут выйти за timeout MCP-клиента, используй:

exec_start или exec_as_start с долгой командой.
exec_status время от времени, передавая stdout.nextOffset и stderr.nextOffset из прошлого ответа.
exec_cancel, если job нужно остановить.
exec_remove после завершения, если нужно очистить in-memory буферы логов.

Так MCP transport остаётся отзывчивым: первый вызов только открывает SSH channel и возвращает jobId; stdout/stderr хранятся в rolling in-memory буферах и читаются потом по job id. Если job получает timeout или отмену, сервер пытается послать сигнал remote process group до закрытия SSH channel.

Интеграции

Все сниппеты ниже используют форму npx (npx -y ssh-chat-mcp) — без установки и путей. Если ставил из исходников, замени { "command": "npx", "args": ["-y", "ssh-chat-mcp"] } на { "command": "node", "args": ["/abs/path/to/ssh-chat-mcp/build/index.js"] }. На Windows некоторым клиентам npx нужно обернуть как "command": "cmd", "args": ["/c", "npx", "-y", "ssh-chat-mcp"].

Claude Code (CLI)

claude mcp add ssh-chat --scope user -- npx -y ssh-chat-mcp

Проверка: /mcp внутри Claude Code.

Claude Desktop

Файл:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "ssh-chat": {
      "command": "npx",
      "args": ["-y", "ssh-chat-mcp"]
    }
  }
}

Полностью перезапусти Claude Desktop (Quit из трея, не просто закрытие окна).

OpenAI Codex CLI

Файл ~/.codex/config.toml (Windows: %USERPROFILE%\.codex\config.toml):

[mcp_servers.ssh-chat]
command = 'npx'
args = ['-y', 'ssh-chat-mcp']
startup_timeout_sec = 30
tool_timeout_sec = 120
enabled = true

Kilo Code

Файл ~/.config/kilo/kilo.jsonc:

{
  "mcp": {
    "ssh-chat": {
      "type": "local",
      "command": ["npx", "-y", "ssh-chat-mcp"],
      "enabled": true,
      "timeout": 120000
    }
  }
}

LM Studio

Файл %USERPROFILE%\.lmstudio\mcp.json (Windows) или аналог на твоей ОС:

{
  "mcpServers": {
    "ssh-chat": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "ssh-chat-mcp"]
    }
  }
}

macOS / Linux:

{
  "mcpServers": {
    "ssh-chat": {
      "command": "npx",
      "args": ["-y", "ssh-chat-mcp"]
    }
  }
}

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "ssh-chat": {
      "command": "npx",
      "args": ["-y", "ssh-chat-mcp"]
    }
  }
}

Continue.dev / Hermes / VS Code MCP-расширения

Большинство MCP-совместимых расширений принимает форму:

{
  "name": "ssh-chat",
  "command": "npx",
  "args": ["-y", "ssh-chat-mcp"],
  "transport": "stdio"
}

Конкретное место хранения JSON смотри в документации клиента.

Любой stdio-совместимый MCP-клиент

Если клиент вообще поддерживает stdio-серверы, укажи:

command: npx
args: ["-y", "ssh-chat-mcp"]
env / cwd: не нужно
transport: stdio

Больше настраивать сознательно нечего.

Пример сценария в чате

Используй MCP ssh-chat. Подключись к 203.0.113.10:22 как deploy с паролем, который я только что дал. Залей D:\Projects\myapp в /tmp/myapp, исключая .git и node_modules. Как appuser создай venv и поставь requirements.txt. Запиши systemd-юнит в /tmp/myapp.service и через sudo mv перенеси в /etc/systemd/system/. Перечитай systemd, включи и запусти myapp.service. Запиши nginx-сайт в /tmp/myapp.nginx, перенеси в /etc/nginx/sites-available/, symlink в sites-enabled/, проверь nginx -t, перезагрузи nginx. Потом disconnect.

Типичная последовательность инструментов:

connect — креды попадают в память.
upload_directory — заливаем проект в /tmp/myapp.
exec — cd /tmp/myapp && ... для непривилегированных шагов.
exec_as — runAs: "appuser" для шагов от имени приложения.
write_remote_file — staging /tmp/myapp.service.
exec — sudo mv /tmp/myapp.service /etc/systemd/system/ && sudo systemctl daemon-reload && sudo systemctl enable --now myapp.
exec — sudo nginx -t && sudo systemctl reload nginx.
disconnect — креды стёрты.

Безопасность

Полная модель угроз — в SECURITY.md. Кратко:

✅ Креды не пишутся на диск.
✅ Вывод и ошибки проходят redaction.
✅ Пароль sudo идёт через stdin, никогда не в командной строке.
✅ POSIX shell quoting на каждом cwd/command.
✅ Строгая валидация runAs как Linux-юзера.
⚠️ Проверка host-key выключена по дизайну (zero-config означает отсутствие on-disk known_hosts). Доверие к хосту — на стороне пользователя.
⚠️ Чёрного списка деструктивных команд нет. Единственная точка контроля — апрув инструментов в твоём MCP-клиенте.
⚠️ Передача пароля или ключа в чат означает, что они видны в транскрипте клиента и могут логироваться провайдером модели. Используй локальные/приватные клиенты (LM Studio, Claude Code локально). При сомнениях — ротация кредов после сессии.

Разработка

npm install
npm run typecheck
npm test
npm run build

Структура проекта:

src/
  index.ts                  MCP stdio-сервер + регистрация инструментов
  types.ts                  общие типы
  ssh/
    connectionManager.ts    Map<name, descriptor> в памяти
    exec.ts                 exec, exec_as (sudo -iu)
    sftp.ts                 upload/download/read/write
  security/
    redact.ts               redaction строк/значений/ошибок
    shellQuote.ts           POSIX-квотинг, валидация Linux-юзера
test/
  redact.test.ts
  shellQuote.test.ts
  errors.test.ts

About AI Platforms / О компании AI Platforms

AI Platforms — Russian systems integrator specialising in on-premises AI: private LLM/RAG stacks (DeepSeek, Qwen, Kimi, GLM), computer-vision for quality control and safety, AI chatbots and autonomous agents, 3D digital avatars, and GPU infrastructure. We deploy AI systems that stay inside our clients' server rooms — not in someone else's cloud.

AI Platforms — российский системный интегратор приватного ИИ: связки LLM/RAG (DeepSeek, Qwen, Kimi, GLM) на собственном железе клиента, компьютерное зрение для контроля качества и безопасности, ИИ-чат-боты и автономные агенты, 3D digital-аватары, GPU-инфраструктура. ИИ-системы остаются в серверной клиента, а не в чужом облаке.

🌐 Web: https://aiplatforms.ru/
✉️ E-mail: akvis-s@mail.ru
☎️ Tel: +7 (812) 987-70-07
📍 196006, St. Petersburg, Mitrofan'evskoe Shosse 29A, office 213

License

MIT © AI Platforms / ООО «Аквис-Сервис».

Available Tools

17 tools

connectOpen SSH connectionA

Open a temporary in-memory SSH connection. Requires host, username, and either password OR privateKey (PEM). All credentials are kept in RAM only and wiped on disconnect. WARNING: this connects to a real remote host and host-key checking is disabled — the calling user is responsible for trust.

ParametersJSON Schema

Name	Required	Description
`host`	Yes	Hostname or IP of the SSH server.
`port`	No	SSH port (default 22).
`password`	No	Optional password. Never logged or returned.
`username`	Yes	Remote SSH username.
`passphrase`	No	Optional passphrase for the private key. Never logged or returned.
`privateKey`	No	Optional PEM-encoded private key. Never logged or returned.
`connectionName`	Yes	Caller-chosen handle used to refer to this connection in later tool calls.
`readyTimeoutMs`	No	How long to wait for the SSH handshake (default 30000).
`keepaliveIntervalMs`	No	Keepalive interval in ms (default 10000).

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description fully discloses critical behaviors: temporary in-memory connection, credential wiping on disconnect, disabled host-key checking, and a trust warning. This goes well beyond the schema.

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 two sentences plus a warning, front-loaded with the action and key requirements. Every sentence provides essential information with no redundancy.

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 description covers purpose, credentials, security, and lifecycle (temporary, wiped). It could mention that connect returns a connection handle (implied by connectionName parameter) but overall is complete for a tool with no output schema.

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 coverage is 100%, so parameters are already documented. The description adds value by clarifying the exclusivity relationship between password and privateKey, and emphasizing credential handling (never logged).

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 opens an SSH connection, specifies required fields (host, username, either password or privateKey), and distinguishes from sibling tools like exec and disconnect by focusing on connection establishment.

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 lists requirements but does not explicitly state when to use this tool versus alternatives (e.g., as a prerequisite for exec calls). It implies usage context but lacks explicit when/when-not guidance.

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

diagnoseDiagnose MCP/SSH stateA

Return explicit local diagnostics: MCP server alive, registered connections, known jobs, or a short SSH probe for a named connection. This helps distinguish server unavailable, SSH unavailable, dead connection, and MCP transport issues.

ParametersJSON Schema

Name	Required	Description	Default
`connectionName`	No	Optional connection to probe with a short `true` command.

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that it returns local diagnostics and performs a short SSH probe for a named connection. It could be more explicit about being read-only, but it implies no 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?

Two sentences succinctly capture purpose, behavior, and usage context. No unnecessary words or repetition.

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?

Complete for a diagnostic tool with one optional parameter and no output schema. Covers all key aspects: what it returns, when it's useful, and the optional probe behavior.

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 coverage is 100% and the description adds meaning by explaining the parameter's effect: a short SSH probe for the named connection, and what happens when omitted (general diagnostics).

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 uses a specific verb ('Return explicit local diagnostics') and resource ('MCP/SSH state'), and clearly differentiates from sibling tools like connect, exec, and file operations by specifying the diagnostic scope.

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 provides clear diagnostic context ('distinguish server unavailable, SSH unavailable, dead connection, and MCP transport issues') but does not explicitly state when not to use or compare directly to siblings.

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

disconnectClose SSH connectionA

Close the named SSH connection and wipe its credentials from memory.

ParametersJSON Schema

Name	Required	Description	Default
`connectionName`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It explicitly mentions wiping credentials from memory, which is a critical security side effect. However, it does not detail other potential behaviors (e.g., error states for non-existent connections).

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 conveys the primary action and an important side effect.

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 (one parameter, no output schema), the description covers the main purpose and a key side effect. It could mention error handling (e.g., if connection doesn't exist) but is largely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It adds no meaning beyond the parameter name 'connectionName' already in the schema. The description fails to clarify what values are valid or provide context for the parameter.

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: close a named SSH connection and wipe credentials. This distinguishes it from sibling tools like 'connect' (opens a connection) and 'list_connections' (lists 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 after a connection is established but does not explicitly state when to use this tool vs alternatives, nor does it provide contextual guidance such as prerequisites or when not to use it.

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

download_fileDownload a remote file to local disk (SFTP)A

Download a remote file to the local filesystem via SFTP. File content is not included in the tool response; only the byte count.

ParametersJSON Schema

Name	Required	Description	Default
`localPath`	Yes
`remotePath`	Yes
`mkdirParents`	No
`connectionName`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses that response excludes file content and includes byte count, but does not explain overwrite behavior, permission requirements, or error handling. Adequate but with gaps.

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?

Two concise sentences with key information front-loaded. Every sentence adds value without redundancy.

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?

Given 4 parameters, no output schema, many siblings, and no annotations, description lacks parameter guidance, usage context, and comparisons to alternatives. Leaves significant gaps for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage and description provides no parameter explanations. Parameter names are self-explanatory (localPath, remotePath, connectionName, mkdirParents), but description adds no value beyond naming. Baseline for low coverage is description must compensate; it does not.

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 action (download), resource (remote file), method (SFTP), and a key behavioral detail (response contains only byte count, not content). Distinguishes from siblings like read_remote_file.

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?

Implies when not to use (when file content is needed) but does not explicitly state when to use vs. alternatives like upload_file or read_remote_file. No guidance on preconditions.

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

execRun a shell command on the remote hostA

Execute a shell command over SSH on the named connection. WARNING: this runs real commands on a real remote machine — destructive operations are NOT blocked by this server. The MCP client / approval layer is responsible for confirming dangerous commands with the user.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Optional remote working directory. Wrapped as `cd <cwd> && <command>`.
`stdin`	No	Optional stdin to feed to the command.
`command`	Yes	Shell command to execute on the remote host.
`timeoutMs`	No	Wall-clock timeout in ms (default 120000).
`connectionName`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full transparency burden. It explicitly warns that 'destructive operations are NOT blocked by this server', clearly disclosing the risk. However, it does not mention return values, error behavior, or success/failure indicators.

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 extremely concise: two sentences that directly state the purpose and a critical warning. No superfluous words, front-loaded with the core action.

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?

Given 5 parameters, no output schema, and no annotations, the description should provide more context about what the tool returns, error handling, or when to use specific parameters (e.g., cwd, stdin). The existing warning is important but insufficient for full usability.

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 80%, so most parameters are already explained in the schema. The description adds minimal additional meaning beyond the schema details (e.g., no new context for parameters).

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 'Execute a shell command over SSH on the named connection', specifying the action, protocol, and target. It directly matches the tool name 'exec' and its title, and is distinguishable from siblings like 'exec_as' or 'exec_start' which have different scopes.

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 includes a strong warning about destructive operations and the responsibility of the MCP client, but does not provide explicit guidance on when to use this tool versus its siblings (e.g., exec_as for a different user, exec_start for background).

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

exec_asRun a command as another Linux user (sudo)A

Run a command non-interactively as another Linux user via sudo -S -p '' -iu <runAs> -- bash -lc <command>. The optional sudoPassword is piped to stdin and is never returned or logged. runAs is strictly validated as a Linux username. WARNING: this performs privileged actions on the remote host.

ParametersJSON Schema

Name	Required	Description
`runAs`	Yes	Target Linux username, e.g. 'appuser'. Strictly validated.
`command`	Yes	Command to run as the target user.
`timeoutMs`	No
`sudoPassword`	No	Optional sudo password. Piped via stdin; never logged or returned.
`connectionName`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description carries full transparency burden. It discloses that sudoPassword is piped to stdin and never logged/returned, runAs is strictly validated, and the action is privileged. The exact shell command is shown, providing clear insight into execution behavior. A minor gap is the lack of detail on 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.

Conciseness5/5

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

The description is three concise sentences, each serving a clear purpose: stating the action, detailing a key behavioral trait, and issuing a warning. No unnecessary words or redundancy.

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 5 parameters, no output schema, and no annotations, the description covers the essential security and execution details but omits return value format, timeout behavior, error scenarios, and prerequisites. It is adequate but not fully comprehensive.

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 60% (descriptions for runAs, command, sudoPassword). The description repeats the schema notes for runAs and sudoPassword but adds no new information. It does not address connectionName or timeoutMs. The added value is marginal, so baseline 3 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 'Run a command as another Linux user', specifying a concrete verb and resource. It details the non-interactive nature and the sudo mechanism, which distinguishes it from sibling tools like 'exec' (likely runs as current user) and 'exec_as_start' (probably asynchronous). The warning about privileged actions further clarifies its purpose.

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 use for running commands as a different user with sudo, but does not explicitly guide when to use this tool versus alternatives like 'exec' or 'exec_as_start'. It lacks prerequisites (e.g., sudoers configuration) and does not mention when not to use it.

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

exec_as_startStart a long-running command as another Linux userA

Start a sudo -iu command and return immediately with a jobId. Read it with exec_status; stop it with exec_cancel. The optional sudoPassword is piped through stdin and never logged.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Optional remote working directory.
`runAs`	Yes	Target Linux username, e.g. 'appuser'. Strictly validated.
`command`	Yes	Command to run as the target user.
`timeoutMs`	No
`sudoPassword`	No	Optional sudo password. Piped via stdin; never logged or returned.
`connectionName`	Yes
`maxBufferBytes`	No

TDQS

A4.1/5.0

Behavior4/5

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

Without annotations, the description covers key behaviors: asynchronous execution (returns jobId), sudo -iu invocation, password handling via stdin with no logging. Missing: side effects, error conditions, timeout behavior, or return value format beyond jobId.

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?

Two sentences: first states the primary action and key output (jobId), second references sibling tools and highlights password security. No fluff, front-loaded.

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?

No output schema or annotations, so description must carry the full burden. It explains core behavior but omits details like error handling, authentication needs, or exact response structure. Adequate for simple usage but not robust for an AI agent.

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 57% (4 of 7 parameters have schema descriptions). The description adds value for sudoPassword (piped stdin, not logged) but doesn't elaborate on other parameters beyond schema. Since schema covers some, description is adequate but not compensating for the 43% uncovered.

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 starts a long-running command as another user via sudo, returns a jobId immediately, and distinguishes itself from siblings like exec_status and exec_cancel. The verb 'Start' and resource 'long-running command' are specific.

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 tells the agent to use exec_status to read output and exec_cancel to stop the command. It explains that the password is never logged, but does not explicitly explain when not to use this tool versus exec_as or exec_start (e.g., synchronous alternatives).

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

exec_cancelCancel a long-running command jobA

Best-effort cancellation for a job. If the remote job PID is known, the MCP server sends the signal to the remote process group, then closes the SSH channel.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes
`signal`	No	Signal name without SIG prefix, e.g. TERM or KILL (default TERM).

TDQS

A3.5/5.0

Behavior3/5

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

Discloses best-effort cancellation, signal sending, and SSH channel closure. Without annotations, this adds behavioral context, but does not mention potential side effects or failure scenarios.

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?

Description is a single sentence, front-loaded with core action, and no unnecessary words. Every part is valuable.

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?

Adequate for a simple cancellation tool, but lacks information about return values or success indicators, especially since no output schema is provided.

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 50% (signal param has description). Tool description adds no parameter info beyond schema, so it meets baseline but does not compensate for the half of parameters without schema descriptions.

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 cancels a long-running command job and explains the mechanism (sends signal to remote process group, closes SSH channel). This distinguishes it from sibling tools like exec_start or exec_status.

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 explicit guidance on when to use this tool versus alternatives like exec_remove. Usage context is implied but not stated, leaving ambiguity for the AI agent.

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

exec_jobsList long-running command jobsB

List known exec jobs and their statuses. Output is metadata only, without logs.

ParametersJSON Schema

Name	Required	Description	Default
`connectionName`	No

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that output is metadata-only and does not include logs, offering some behavioral insight. However, it omits details about permissions, side effects, or whether the operation is read-only.

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 consists of two concise sentences, each serving a clear purpose: stating the action and clarifying output. No extraneous information, perfectly front-loaded.

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 the single optional parameter and no output schema, the description provides the core function but lacks completeness regarding parameter semantics and use cases. It is minimally adequate but leaves gaps for an agent to make fully informed decisions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single parameter 'connectionName' with no description, and the tool description does not explain its purpose or usage. Schema coverage is 0%, and the description fails to compensate, leaving the parameter ambiguous.

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 verb 'List' and the object 'known exec jobs and their statuses'. It also specifies the output nature ('metadata only, without logs'), distinguishing it from sibling tools like exec_status that show a single job status.

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?

The description does not provide any explicit guidance on when to use this tool versus alternatives like exec_status or exec. It neither states prerequisites nor exclusions, leaving the agent to infer usage solely from the tool name and title.

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

exec_removeRemove a completed command jobB

Forget a completed/cancelled/failed job and drop its buffered stdout/stderr.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes

TDQS

B3/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It mentions dropping buffered stdout/stderr, which is a behavioral trait, but does not state whether the job record is fully removed, if this is irreversible, or any authorization needs. Major gaps remain.

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 is front-loaded with key information. However, it could be more explicit (e.g., 'Remove the job record' instead of 'Forget'). Minimal waste.

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?

The description lacks critical constraints: it does not specify that the job must be in a terminal state (completed/cancelled/failed) and not running. It also does not clarify what happens to the job record in the system. Given no output schema, more context is needed for safe use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes jobId as a required string with no description (0% coverage). The description adds no further meaning about the parameter beyond the tool's context, so it provides no added value for understanding the parameter.

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 removes or forgets a completed/cancelled/failed job and discards its buffered output. It uses specific verbs and resource, differentiating it from siblings like exec_cancel (which cancels running jobs) and exec_status (which retrieves status).

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 a job is completed, cancelled, or failed, but does not explicitly say when not to use (e.g., on running jobs) or mention alternative tools. Guidance is adequate but not explicit.

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

exec_startStart a long-running shell commandA

Start a command over SSH and return immediately with a jobId. Use exec_status to read stdout/stderr later and exec_cancel to stop it. This avoids MCP client tool-call timeouts for git clone, pip install, apt install, dkms builds, reboot waits, and similar long operations.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Optional remote working directory. Wrapped as `cd <cwd> && <command>`.
`stdin`	No	Optional stdin to feed to the command.
`command`	Yes	Shell command to execute on the remote host.
`timeoutMs`	No	Optional wall-clock timeout in ms. 0 or omitted means no MCP-side timeout.
`connectionName`	Yes
`maxBufferBytes`	No	Rolling stdout/stderr buffer limit per stream (default 1000000).

TDQS

A4/5.0

Behavior3/5

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

Without annotations, description reveals key behaviors: returns immediately with jobId, runs over SSH, buffer limits. But it omits error handling, connection failure, and resource cleanup details.

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?

Two concise sentences: first states purpose, second gives usage context and examples. Zero wasted words.

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 no output schema, description mentions return of jobId and references related tools. It covers main use cases but lacks details on error states and output format.

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 covers 83% of parameters with descriptions; description adds no extra parameter-level meaning beyond what schema provides. Baseline score 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?

Title and description clearly state that exec_start starts a long-running shell command over SSH and returns immediately with a jobId. It distinguishes from sibling tools like exec by emphasizing avoidance of MCP client timeouts.

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?

Description explicitly says when to use: for long operations like git clone, pip install, etc. It directs to exec_status and exec_cancel for follow-up. However, it does not explicitly state when not to use or contrast with exec.

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

exec_statusRead a long-running command jobA

Return job status plus stdout/stderr slices. Pass stdoutOffset/stderrOffset from the previous response's nextOffset fields to read incrementally.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes
`maxBytes`	No
`stderrOffset`	No
`stdoutOffset`	No

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It effectively discloses the incremental reading behavior and that it returns slices of output. It implies a read-only operation (status and output) without side effects, which is sufficient transparency for a non-destructive 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?

Two succinct sentences, front-loading the core purpose. Every word adds value, no repetition or filler. The structure is ideal for quick comprehension.

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 no output schema, the description should at least mention that nextOffset fields are included in the response to enable the incremental pattern. It says 'Return job status plus stdout/stderr slices' but omits the critical nextOffset fields. It is sufficient for basic use but lacks full completeness for a robust polling pattern.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning. It explains the role of stdoutOffset and stderrOffset (from previous response's nextOffset fields), but does not explain maxBytes, which has a maximum of 5 MB. jobId is obvious from context, but the lack of explanation for maxBytes leaves ambiguity.

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 returns job status and stdout/stderr slices, distinguishing it from sibling tools like exec_start (starts jobs) and exec_cancel (cancels jobs). The verb 'Return' and the specific resource 'job status plus stdout/stderr slices' make the purpose unambiguous.

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 specific guidance on using stdoutOffset and stderrOffset for incremental reading, which is valuable. However, it does not explicitly state when to use this tool versus alternatives like exec (which might wait for completion) or exec_jobs (which lists jobs). It implies usage after starting a job but lacks explicit when-not instructions.

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

list_connectionsList active SSH connectionsA

List currently registered SSH connections. Returns only non-sensitive metadata (connectionName, host, port, username, connectedAt, status).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description carries the full burden. It explicitly states the tool returns non-sensitive metadata, implying a read-only operation with no side effects. However, it could be more explicit about the read-only nature and any prerequisites.

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 action and then provides specific details. Every word adds value; no redundancy.

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 operation with no parameters and no output schema, the description adequately covers what the tool does and what data is returned. It could mention the response format or behavior when no connections exist, but overall 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 (schema coverage 100%). Per rubric, a 0-parameter tool gets a baseline of 4. The description adds context by listing returned fields, which is helpful even though it is not about parameters.

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 lists currently registered SSH connections and specifies the returned non-sensitive metadata fields (connectionName, host, port, username, connectedAt, status). The title also reinforces the purpose. It is distinct from sibling tools like connect, disconnect, and exec.

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 does not explicitly state when to use this tool versus alternatives. While it is implied that listing connections is separate from connecting or executing commands, there is no guidance on prerequisites or when another tool might be preferred.

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

read_remote_fileRead a remote file as text (SFTP)A

Read up to maxBytes of a remote file as UTF-8 text. Content is redacted for known secret patterns before being returned.

ParametersJSON Schema

Name	Required	Description
`maxBytes`	No	Maximum bytes to read (default 200000, hard cap 10000000).
`remotePath`	Yes
`connectionName`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Discloses redaction of secrets and byte limit, but lacks details on error handling, permissions, symlink behavior, or encoding fallback. With no annotations, more transparency is needed.

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?

Two sentences, no fluff, directly conveys core functionality and key behavioral note.

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?

No output schema, missing return structure and behavior for binary files or non-UTF-8 encoding. Adequate for simple reads but incomplete for edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 33%; description only reinforces maxBytes. Parameters remotePath and connectionName lack both schema and description elaboration, leaving agents guessing.

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 reads a remote file as UTF-8 text with a byte limit and redaction, distinguishing it from siblings like write_remote_file and download_file.

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?

No explicit guidance on when to use this tool vs alternatives like download_file or exec. The purpose is clear from sibling names, but no when-not-to-use context is provided.

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

upload_directoryRecursively upload a local directory (SFTP)A

Recursively upload a local directory tree to the remote host via SFTP. Excludes are caller-supplied (no project dirs hardcoded). Symlinks are not followed unless explicitly requested.

ParametersJSON Schema

Name	Required	Description
`exclude`	No	Basenames to skip (e.g. ['.git','node_modules']).
`localPath`	Yes
`remotePath`	Yes
`mkdirParents`	No
`connectionName`	Yes
`followSymlinks`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must carry behavioral transparency. It discloses two key behaviors: excludes are not hardcoded, and symlinks are not followed by default. However, it omits other important behaviors like overwrite policy, error handling, or the need for a prior connection, which leaves gaps.

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 extremely concise, consisting of two short sentences. It front-loads the main action and includes critical details without any fluff, making it efficient for an agent to parse.

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?

For a tool with 6 parameters and no output schema, the description provides the most essential context (recursive upload, excludes, symlinks) but misses details like the role of connectionName, whether mkdirParents is automatic, and what happens on error. It is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 17% (only 'exclude' has a description). The description adds semantic value for 'exclude' and 'followSymlinks', but the remaining 4 parameters (localPath, remotePath, connectionName, mkdirParents) receive no additional explanation beyond their names, which is insufficient given the low coverage.

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: recursively upload a local directory tree via SFTP. It specifies the resource (local directory tree) and method (SFTP), distinguishing it from sibling tools like upload_file that handle single files.

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 implicit guidance by noting that excludes are caller-supplied and symlinks are not followed unless requested. However, it does not explicitly state when to use this tool versus alternatives like upload_file, nor does it mention prerequisites such as needing an active connection.

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

upload_fileUpload a local file to the remote host (SFTP)C

Upload a single local file to the remote host via SFTP. localPath and remotePath are taken from arguments only — no paths are hardcoded.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Optional POSIX mode bits, e.g. 420 = 0o644.
`localPath`	Yes	Absolute or relative local file path.
`remotePath`	Yes	Absolute remote file path.
`mkdirParents`	No	If true, create remote parent directories as needed.
`connectionName`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only notes that paths come from arguments and are not hardcoded. Missing critical details: whether existing files are overwritten, what happens on failure, permission handling, or if the tool is idempotent.

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 concise with two front-loaded sentences. Every word adds value, but there is room to include more behavioral details without becoming verbose.

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?

Given 5 parameters, no output schema, and sibling tools, the description lacks completeness. It does not explain the return value (e.g., success/failure), prerequisites (e.g., need for a connection), or effects like overwriting. The tool is a mutation, yet behavioral context is minimal.

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 high (80%), so baseline is 3. The description adds minimal value beyond the schema, only reinforcing that paths are from arguments. It does not clarify the purpose of 'mode' or 'mkdirParents' beyond the schema, nor does it describe the undocumented 'connectionName' parameter.

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 action ('Upload') and resource ('single local file'), specifying the method (SFTP). It implicitly distinguishes from sibling 'upload_directory' by mentioning 'single local file', but does not explicitly contrast with other related tools like 'write_remote_file'.

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 is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an active connection), when not to use it (e.g., for directories), or refer to sibling tools like 'upload_directory' or 'write_remote_file'.

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

write_remote_fileWrite a remote file (SFTP)B

Write a UTF-8 text payload to a remote file via SFTP. Useful for staging config files (e.g. into /tmp) which a subsequent exec can move into place with sudo mv / tee.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No
`content`	Yes
`remotePath`	Yes
`mkdirParents`	No
`connectionName`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Mentions UTF-8 text payload but lacks details on overwrite behavior, permission handling, error cases, and mode parameter. Incomplete for a write tool.

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?

Short and front-loaded, but lacks essential information. One sentence plus a hint. Could be more structured by listing key parameters or constraints.

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?

Five parameters, no output schema, no annotations. Description is too brief to guide correct invocation. Missing required parameter details, return value, and error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description adds no meaning to any parameter (mode, remotePath, content, mkdirParents, connectionName). The word 'payload' loosely relates to content but no explicit explanations.

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 action (write), resource (remote file), protocol (SFTP), and provides a specific use case (staging config files). Distinguishes from siblings like read_remote_file and upload_file.

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?

Suggests when to use (staging config files for later movement by exec) and implies an alternative workflow (exec for moving). Does not explicitly state when not to use or compare to upload_file, but provides useful context.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: connection management, file transfers, command execution (sync, async, sudo), and diagnostics. Even the exec family differentiates immediate vs async and different user contexts without ambiguity.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern (e.g., download_file, exec_status) or single verb (connect, exec). The exec_ family uses a uniform prefix. All names are lowercase with underscores, making them predictable.

Tool Count5/5

With 17 tools, the server is well-scoped for SSH operations. It covers all essential actions without unnecessary duplication or bloat. Each tool earns its place in the set.

Completeness5/5

The tool surface is comprehensive: connection lifecycle, command execution (synchronous, asynchronous, sudo, with status/cancel), file transfer (single, directory, read, write), and diagnostics. Gaps are minimal and easily addressed via exec.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
browser-ssh
com.browserssh
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Shell Access File Systems
2

Related MCP Servers

Simple SSH MCP Server
Shell Access Command Line OS Automation
bhayanak
A
license
Not graded
quality
D
maintenance
An MCP server that gives AI assistants full SSH/SFTP remote operations — session management, command execution, interactive shells, file transfers, port forwarding, and system diagnostics.
Updated 5 months ago (2026-04-17 09:50 UTC)
2
MIT
ssh-mcp
Shell Access Command Line
slepp
A
license
A
quality
C
maintenance
An MCP server that gives AI agents SSH access to remote machines through your local OpenSSH client, enabling remote command execution, file transfer, persistent shell sessions, and port forwarding.
Updated 2 months ago (2026-07-09 00:20 UTC)
17
16
MIT
ssh-client-mcp-server
Shell Access Command Line
jordanburke
A
license
Not graded
quality
A
maintenance
A local MCP server that enables LLMs to execute shell commands on remote hosts over SSH with multiple authentication methods.
Updated 2 months ago (2026-07-04 19:24 UTC)
35
3
MIT
sshand
Shell Access Command Line File Systems
muradmalik23
A
license
A
quality
A
maintenance
An open MCP server that gives any AI agent SSH access to remote Linux/Unix machines — shell commands, file read/write, and SFTP transfers.
Updated 2 months ago (2026-06-24 05:28 UTC)
11
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aiplatforms-ru/ssh-chat-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server