The SSH MCP server enables AI agents to manage SSH environments, diagnose connectivity issues, and perform remote operations securely.
SSH Environment Management & Diagnostics
Ensure SSH agent is running, list/load SSH keys, resolve SSH config (including ProxyJump/bastion hosts)
Fix stale known_hosts entries, test Git-over-SSH authentication (GitHub, GitLab, etc.), and run quick connectivity checks
Full SSH diagnostics (ssh_diagnose) — comprehensive check of agent, keys, config, known_hosts, and connectivity with exact fix commands
Remote Command Execution
Run shell commands on a remote host (ssh_exec) with support for pipes, env vars, and configurable timeouts
Execute commands in parallel across multiple hosts (ssh_multi_exec) with per-host results
Configurable command whitelist/blacklist policies for security
Remote File Operations (SFTP)
Read, write, upload, and download files
List directories, get file metadata (size, permissions, timestamps)
Create directories (with recursive -p support) and delete files or empty directories
Higher-Level Remote Operations
Search for files (ssh_find) with filters for name, type, size, depth, and modification time
Tail log files (ssh_tail) with optional grep filtering
Check systemd service status (ssh_service_status) — state, PID, uptime, and description
Key Features
Connection pooling — reuses SSH connections automatically (60s idle timeout, 100 connection cap)
Host key verification — TOFU on first connect, MITM protection on subsequent connections
Auto-diagnostics — failed operations automatically include diagnostic hints in error responses
Windows support — detects OpenSSH Authentication Agent via named pipe
Facilitates Ansible deployments by managing SSH keys, agent, and connectivity, resolving host key issues and ensuring reliable SSH access to target hosts.
Ensures Git-over-SSH authentication to Bitbucket by managing SSH keys, diagnosing permission errors, and fixing known host key issues so that git pull/push/clone works.
Enables Composer to install packages from private repositories over SSH by loading the correct SSH keys into the agent and diagnosing authentication failures.
Supports SSH access to DigitalOcean droplets by managing SSH keys, host keys, and providing diagnostics to resolve connection issues.
Resolves Git-over-SSH authentication failures for clone, pull, push, and other operations by managing the SSH agent, keys, and known hosts.
Ensures Git-over-SSH authentication to GitHub by managing SSH keys, diagnosing permission errors, and fixing known host key issues.
Ensures Git-over-SSH authentication to GitLab by managing SSH keys, diagnosing permission errors, and fixing known host key issues.
Enables npm to install packages from private registries over SSH by managing SSH agent, keys, and resolving authentication failures.
Facilitates Terraform operations on remote hosts by managing SSH keys, agent, and connectivity diagnostics to ensure secure and reliable access.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SSH MCP Server run df -h on my production server"
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.
Make SSH work for AI tools. MCP server that manages your SSH environment, diagnoses what's broken, fixes it, and gives your agent remote access to anything.
Built and maintained by Yaw Labs.
One click adds this to your local Yaw MCP config so it's available in every Yaw Terminal session. Or install manually below.
AI CLI tools run in subprocesses where SSH is constantly broken. The agent tries to git pull and gets Permission denied (publickey). It tries to SSH into a server and the agent socket is stale. It tries to deploy and the host key changed because the instance was recreated. Every time, the AI has no idea what's wrong and spirals.
This happens across every situation that needs SSH keys:
Git — clone, pull, push, fetch, submodules, LFS
Package managers — npm install, pip install, go get, cargo, composer from private repos
Server access — SSH, SCP, SFTP, rsync
Tunneling — port forwarding to databases, SOCKS proxies
Deployment — Ansible, Terraform, Capistrano, deploy scripts
Cloud — AWS EC2, GCP, Azure, DigitalOcean, any VPS
ssh-mcp fixes this. It manages the SSH agent, loads keys, diagnoses failures with actionable fix commands, and provides remote operations — all as MCP tools your AI agent can call.
Related MCP server: Scout MCP
Add to your MCP client config:
{
"mcpServers": {
"ssh": {
"command": "npx",
"args": ["-y", "@yawlabs/ssh-mcp@latest"]
}
}
}On Windows wrap with cmd /c since Node 20+ can't spawn .cmd files directly:
{
"mcpServers": {
"ssh": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@yawlabs/ssh-mcp@latest"]
}
}
}The @latest tag makes npx re-resolve against the registry on every spawn, so each MCP session uses the newest published version. Or install globally if you'd rather pin (no auto-update):
npm install -g @yawlabs/ssh-mcp
# then in client config: "command": "ssh-mcp"Tools that fix your local SSH setup so everything else — git, deploys, tunnels — stops breaking.
Tool | Description |
| Ensure ssh-agent is running. Starts one if needed and sets env vars for the session. |
| List all SSH keys in ~/.ssh/ with type, fingerprint, and agent status. |
| Load a key into the running agent. Ensures the agent is started first. |
| Resolve the effective SSH config for a host (hostname, user, port, proxy, identity files). |
| Remove a stale host key and re-scan. Fixes "host key verification failed" errors. |
| Test Git-over-SSH auth to GitHub, GitLab, Bitbucket, etc. |
| Quick connectivity test with timing and actionable error details. |
Tool | Description |
| Full SSH environment diagnostic. Checks agent, keys, config, known_hosts, and connectivity. Returns exact fix commands for every failure. |
Tool | Description |
| Execute a command on a remote host. Returns stdout, stderr, and exit code (or |
| Read a file from a remote host via SFTP. |
| Write content to a file on a remote host via SFTP. |
| Upload a local file to a remote host via SFTP. |
| Download a file from a remote host to local filesystem. |
| List files in a directory on a remote host. |
| Get metadata for a file or directory (size, mode in octal, uid/gid, mtime/atime, isFile/isDirectory/isSymbolicLink). Use instead of parsing |
| Create a directory via SFTP. Set |
| Delete a file or empty directory via SFTP. Auto-dispatches unlink vs rmdir based on the path's own type ( |
Tools that wrap common patterns agents build with ssh_exec — faster and less error-prone.
Tool | Description |
| Run a command on multiple hosts in parallel. Returns results per host. Optional |
| Search for files remotely with structured parameters ( |
| Read the last N lines of a file, optionally filtered by a grep pattern. |
| Check systemd service status (active, PID, uptime, description). Flags |
When any remote operation fails, ssh-mcp automatically runs diagnostics and includes the results in the error response. Your agent doesn't need to call ssh_diagnose separately — it gets told what's wrong and how to fix it right in the error message.
Remote operations reuse SSH connections automatically. When your agent makes multiple calls to the same host, the first call opens a connection and subsequent calls reuse it. Connections are kept alive for 60 seconds after the last use, then closed automatically.
The pool caps at 100 active connections by default. Set SSH_MCP_MAX_POOL_SIZE=<n> to raise it for fan-out workloads against many distinct hosts (e.g. ssh_multi_exec across a large fleet). When the cap is reached, the pool evicts an idle entry to make room; if every entry is in use it rejects with Connection pool is full.
All connections respect your ~/.ssh/config. Host aliases, custom ports, usernames, identity files, and ProxyJump settings are used automatically. If you have Host myserver configured in your SSH config, just pass host: "myserver" — ssh-mcp resolves everything.
ProxyJump / bastion hosts are supported automatically. If your SSH config has ProxyJump bastion for a host, ssh-mcp connects through the bastion transparently. Chained proxies work too.
All remote operations verify the server's host key against ~/.ssh/known_hosts:
Known host, key matches — accept.
Known host, key changed — reject (MITM protection). The rejection message distinguishes a genuine key mismatch from "the server offered a key type your known_hosts entry doesn't cover", so a missing ed25519 line doesn't read as an attack.
Unknown host — accept, unless SSH_MCP_STRICT_HOST_KEY=1.
That last branch is trust-always, not TOFU. Real trust-on-first-use pins the key it saw the first time and rejects a change afterwards. The connection path never writes to known_hosts — no tool adds an entry as a side effect of connecting — so connecting pins nothing: every connection to a host absent from known_hosts is a "first" use and is accepted, including one where an attacker swapped the key since your last call. Only hosts put into known_hosts out of band get mismatch protection — by you, by ssh-keyscan, or by ssh_known_hosts_fix, the one tool here that does write the file. Call it explicitly to add an entry so future changes are caught.
For stricter environments, set SSH_MCP_STRICT_HOST_KEY=1 to reject unknown hosts. Add them explicitly with ssh_known_hosts_fix first.
The diagnostic tools (ssh_test, ssh_diagnose) use StrictHostKeyChecking=no for their probe commands. Those probes only run echo SSH_OK — no credentials or data pass through — so the relaxed setting is safe for connectivity testing. Real operations always go through the hostVerifier.
ssh_exec and ssh_multi_exec accept free-form shell commands from the agent. For security-conscious deployments, you can restrict which commands run via two env vars, each accepting a comma-separated list of regex patterns:
SSH_MCP_COMMAND_WHITELIST — if set, the command must match at least one pattern, else it's blocked.
SSH_MCP_COMMAND_BLACKLIST — if set, the command must not match any pattern, else it's blocked.
When both are set, the command must pass both checks (whitelist first, then blacklist). When neither is set (the default), all commands are allowed.
Patterns are JavaScript regexes. Use ^ and $ for anchored matches; otherwise patterns are treated as substring matches. Commas are the delimiter, so a literal comma in a pattern needs to be expressed as \x2c or via a character class.
# Read-only allowlist: only ls / df / cat / find / tail
SSH_MCP_COMMAND_WHITELIST="^ls( .*)?,^df( .*)?,^cat ,^find ,^tail "
# Block destructive ops even if your agent goes off-script
SSH_MCP_COMMAND_BLACKLIST="^rm ,^shutdown,^reboot,^mkfs,^dd if=,>\s*/dev/"Blocked commands surface as a clear error mentioning which pattern (or which env var) rejected the call, so the agent can adapt rather than guess. Policy is enforced before the SSH connection opens — no remote process is started for a blocked command.
ssh_exec and ssh_multi_exec onlyEvery other tool runs unchecked. That splits into two very different cases.
The structured read tools are all exempt, but for two different reasons — they don't reach the remote the same way.
ssh_find, ssh_tail and ssh_service_status do build a shell command (find, tail, systemctl), but from typed parameters with every interpolated value shell-quoted, never from free-form agent input. They're exempt for ergonomics: a tight ^ls whitelist would otherwise force you to allow ^find , ^tail , ^systemctl just to keep those tools working — defeating the point of a tight whitelist.
ssh_ls, ssh_stat, ssh_read_file and ssh_download build no command at all. They're pure SFTP (readdir, stat, readFile, fastGet), so — exactly like the mutating SFTP tools below — there is no command string for a regex to match, and these env vars could not gate them even if you wanted them to. They're grouped with the reads rather than flagged as a gap because they don't mutate remote state. One caveat: ssh_download is non-mutating on the remote only — it writes to whatever local path it's handed, and these env vars don't constrain that either.
The SFTP tools that mutate remote state are also unchecked, and that is a genuine gap — not an ergonomics call. ssh_write_file, ssh_upload, ssh_mkdir, and ssh_delete never build a shell command string, so a command-shaped regex has nothing to match. Concretely: SSH_MCP_COMMAND_BLACKLIST="^rm " does not stop ssh_delete, and SSH_MCP_COMMAND_WHITELIST="^ls " does not stop ssh_write_file. Closing this would need a separate path-policy mechanism, which this server deliberately does not have. If you must prevent remote mutation, drop those four tools from your MCP client's tool allowlist (or run a client that gates them) — these two env vars cannot do it.
env parameter (ssh_exec, ssh_multi_exec)When ssh_exec or ssh_multi_exec is called with env: { KEY: "value" }, the values are injected as a KEY='value' ... shell prefix before the command (see the tool descriptions). Policy is checked against the full prefixed command, not the bare command argument — once, before fan-out, in the ssh_multi_exec case. That's the safer ordering at the protocol layer — but it means whitelist patterns need to anticipate the prefix and must be anchored, not substring matches:
# WRONG -- blocks any ssh_exec call that uses `env`, because the final command
# starts with `KEY='value' ` and never matches `^ls`.
SSH_MCP_COMMAND_WHITELIST="^ls "
# RIGHT -- allow zero or more `KEY='value' ` prefixes before the real command.
SSH_MCP_COMMAND_WHITELIST="^([A-Za-z_][A-Za-z0-9_]*='[^']*' )*ls( |$)"You don't have to diagnose this from a bare rejection: when a whitelist blocks a call that used env, the error appends a note explaining that the prefix is why the ^ anchor stopped matching, and suggests the tolerant pattern above.
Avoid substring-match patterns like ls if you're worried about a hostile agent. An agent could pass env: { ATTACK: " ls " } to make the final command ATTACK=' ls ' rm -rf /, which matches a substring ls and bypasses the whitelist. Anchored patterns of the form above don't have this weakness because they require the real command name to follow the env-prefix block, not appear inside a quoted env value.
Blacklists need the same care. ^rm blocks a bare rm call, but doesn't block FOO='bar' rm. Use the same env-prefix-tolerant anchor:
SSH_MCP_COMMAND_BLACKLIST="^([A-Za-z_][A-Za-z0-9_]*='[^']*' )*rm( |$)"If you don't trust the agent's env values at all, the simplest mitigation is to leave env unused in your client config and pass everything through the command string yourself.
On Windows, ssh-mcp uses the OpenSSH Authentication Agent's \\.\pipe\openssh-ssh-agent named pipe automatically when SSH_AUTH_SOCK is not set. No SSH_AUTH_SOCK needed — just make sure the OpenSSH agent service is running.
ssh_agent_ensure and ssh_diagnose probe that pipe and tell you if the service is down. Remote operations do not: they assume the pipe and let the connection fail on its own if the agent isn't there. That is why a stopped agent service shows up as an auth failure rather than an "agent not running" error until you run the diagnostic tools.
All remote operations accept connection parameters:
Parameter | Description | Default |
| SSH hostname or IP (required) | — |
| SSH port | From SSH config or |
| SSH username | From SSH config or current user |
| Path to SSH private key | Auto-detect |
| SSH password (prefer keys) | — |
Auth resolution. An explicit credential wins outright and nothing else is offered. With neither given, ssh-mcp offers the ssh-agent and one on-disk key together — the way the OpenSSH client does — and lets the server pick during the auth exchange. It is not a strict first-match chain past step 2.
Explicit privateKeyPath — used alone. The agent is not offered and no other key is read.
Explicit password — used alone, same as above.
Neither given — both of the following are configured on the same connection:
ssh-agent — SSH_AUTH_SOCK, or on Windows the \\.\pipe\openssh-ssh-agent named pipe. The Windows pipe is assumed unconditionally; ssh-mcp does not check that the OpenSSH Authentication Agent service is actually running.
One on-disk key — the first readable path in ssh -G <host>'s identityfile list. OpenSSH emits that list for every host, including one with no IdentityFile line (it defaults to ~/.ssh/id_rsa, id_ecdsa, id_ecdsa_sk, id_ed25519, id_ed25519_sk), so this is the normal path — not a path reserved for hosts you configured an identity for. ssh-mcp's own built-in list (~/.ssh/id_ed25519, id_rsa, id_ecdsa) is a fallback used only when ssh -G cannot run at all, e.g. no SSH client installed.
Two things worth knowing about step 3:
Only one on-disk key is ever offered — the first candidate that exists. ssh-mcp does not walk the whole identity list the way ssh does, so if the first readable key is the wrong one, authentication rests on the agent's keys. Pass privateKeyPath to force a specific key.
When an agent is configured, an encrypted on-disk key is skipped and the scan moves to the next candidate. The underlying ssh2 library parses privateKey eagerly and errors with "no passphrase given" on an encrypted key, which would break the common setup of an encrypted key on disk with its decrypted copy loaded in the agent. With no agent configured, the first existing key is loaded regardless of encryption and ssh2 surfaces the passphrase error itself. Because the Windows pipe above is assumed unconditionally, the skip is always in force on Windows.
Agent calls ssh_git_check → "Permission denied. Your SSH key is not registered with github.com."
Agent calls ssh_key_list → finds id_ed25519 exists but is not loaded
Agent calls ssh_key_load("~/.ssh/id_ed25519") → "Key loaded"
Agent calls ssh_git_check → "Git SSH authentication to github.com succeeded as username"
Agent runs git pull → worksAgent calls ssh_exec on server → error: "Host key verification failed"
(auto-diagnostics included in error: "Fix with ssh_known_hosts_fix")
Agent calls ssh_known_hosts_fix("my-server") → "Host key refreshed"
Agent calls ssh_exec → worksAgent calls ssh_test("new-server") → "Connection refused at new-server:22"
Agent calls ssh_diagnose("new-server") → full report showing agent running, keys loaded, but host unreachable
Agent reports: "SSH server isn't running on new-server or port 22 is blocked"import { connect, exec, diagnose, ensureAgent, listSshKeys, checkGitSsh, ConnectionPool } from '@yawlabs/ssh-mcp';
// Fix SSH environment
const agent = ensureAgent();
console.log(agent.message);
// Check git access
const git = checkGitSsh('github.com');
console.log(git.message);
// List available keys
const keys = listSshKeys();
for (const key of keys) {
console.log(`${key.name} (${key.type}) - ${key.loadedInAgent ? 'loaded' : 'not loaded'}`);
}
// Run a remote command (one-off)
const client = await connect({ host: 'my-server', username: 'deploy' });
const result = await exec(client, 'uptime');
console.log(result.stdout);
client.end();
// Run multiple commands with connection pooling
const pool = new ConnectionPool();
await pool.withConnection({ host: 'my-server' }, async (client) => {
const r1 = await exec(client, 'uptime');
console.log(r1.stdout);
});
// Connection stays open for 60s — next call reuses it
await pool.withConnection({ host: 'my-server' }, async (client) => {
const r2 = await exec(client, 'df -h');
console.log(r2.stdout);
});
pool.drain(); // close all connections when done
// Diagnose issues
const report = diagnose('my-server');
console.log(report.overall); // "ok" | "warning" | "error"
for (const check of report.checks) {
console.log(`[${check.status}] ${check.name}: ${check.message}`);
}Node.js 18+
SSH client installed (for diagnostics and environment management)
MIT
Ensure 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: starts a new agent if needed and sets environment variables. However, it omits potential side effects (e.g., overwriting existing SSH_AUTH_SOCK or SSH_AGENT_PID). With no annotations, the description carries the full transparency burden, and it is mostly clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential: first explains what the tool does, second gives usage context. No redundant or extraneous text. Structure is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema) and the description fully covers its purpose, behavior, and when to use it. It is complete for an environment setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (empty). Per guidelines, baseline score for 0 parameters is 4. The description adds no parameter info, which is appropriate since none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Ensure' with resource 'ssh-agent' and specifies outcomes: running, reachable, sets environment variables. It distinguishes from sibling tools (e.g., ssh_exec, ssh_download) by focusing on agent management rather than file operations or execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this FIRST when SSH operations fail with agent-related errors.' This tells when to use the tool but does not explicitly mention when not to use it (e.g., if agent is already functional). The 'FIRST' strongly implies it is a prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the effective SSH configuration for a host. Shows hostname, user, port, identity files, proxy settings, and all other options from ~/.ssh/config. Use this to understand how SSH will connect to a host.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates a read-only operation by stating it 'shows' configuration, but does not mention permissions, side effects, or what happens if the host is not found. It adds some value beyond the schema but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a clear user instruction. Every sentence is essential and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains the function and output. It lacks details about edge cases (e.g., missing config) but is mostly complete given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for 'host' ('SSH hostname or IP address'). The description confirms the parameter's role but adds no extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves effective SSH configuration for a host and lists specific items it shows (hostname, user, port, etc.). It distinguishes from sibling tools like ssh_exec or ssh_diagnose by focusing on configuration lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to understand how SSH will connect to a host,' which provides clear context. However, it does not explicitly mention when not to use it or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete 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.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Absolute path of the file or empty directory to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses key behaviors: auto-detection of path type, unsupported recursive delete, and the underlying SFTP ops used. However, it does not mention what happens when trying to delete a non-empty directory or what the return value looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence defines purpose and behavior, second sentence states limitation and alternative. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return values are not explained. The description covers core behavior, limitations, and alternatives well. Lacks details on error handling and authentication flow, but these are partially covered by the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The description adds contextual value for the 'path' parameter by noting auto-detection but does not elaborate on other parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool deletes a file or empty directory on a remote host via SFTP, specifying the specific resources (files/symlinks and empty dirs) and action. It also differentiates itself from sibling tool ssh_exec by noting that recursive delete is intentionally unsupported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (delete files/empty dirs) and when not to (recursive delete). Provides a clear alternative: use ssh_exec with `rm -rf` for recursive deletion, with rationale about traceability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose 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.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Describes checks but does not disclose whether the tool modifies any state (e.g., known_hosts) or if the test connection is read-only. Lacks explicit safety info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover purpose, actions, and usage context. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description does not mention what the tool returns (e.g., summary or detailed report). An agent lacks info on output format, making it incomplete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both host and port have descriptions. The description adds no further meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diagnoses SSH connectivity issues, listing specific checks (ssh-agent, keys, known_hosts, config, test connection). It distinguishes from many sibling tools that perform specific operations like exec, download, or upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before SSH operations if connectivity issues are suspected, or after a failed SSH operation. This provides clear context, though it does not explicitly name alternative sibling tools like ssh_test.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a file from a remote host to local filesystem via SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| remotePath | Yes | Absolute path to the remote file | |
| localPath | Yes | Local path to save the downloaded file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It only states basic functionality. Missing details: overwrite behavior, error handling, authentication requirements, and any side effects. The password security warning is in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys action and method. No superfluous words; front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 100% schema coverage, and no output schema, the description is minimal. It does not explain return values, progress indication, cancellation, or error handling. For a simple file download, the core behavior is implied but not fully explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description (e.g., port, privateKeyPath, password warning). The tool description adds no further parameter meaning beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Download a file), resource (from remote host to local filesystem), and method (via SFTP). It distinguishes this tool from siblings like ssh_upload, ssh_exec, and ssh_read_file by specifying the direction and protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., SSH connectivity, key-based auth), nor does it advise against using it for directories or large files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute 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 stdout, stderr, and exit code. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| command | Yes | Shell command to execute on the remote host (interpreted by the remote login shell) | |
| env | No | Environment variables to set for this command. Injected as a `KEY='value' ...` prefix; works on any sshd regardless of AcceptEnv config. Values are POSIX-single-quoted, so any byte is safe. | |
| timeout | No | Command timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: shell interpretation of metacharacters, returns stdout/stderr/exit code, env injection method, and policy checks. With no annotations, the description carries full burden and covers essential behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first defines purpose, second explains shell behavior and returns, third covers env usage and policy. Front-loaded, no redundant information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, env, and policy but lacks details on timeout behavior, error handling, or structured return format. Since no output schema exists, the description should provide more on the response shape. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 8 parameters (100%). The description adds no new parameter-level meaning beyond what the schema already provides (e.g., env injection is detailed in schema). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Execute a command on a remote host via SSH'. Identifies the resource (remote host) and action (execute command), and differentiates from siblings like ssh_read_file or ssh_download by focusing on arbitrary command execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Does not compare to sibling tools like ssh_multi_exec or ssh_read_file, leaving the agent to infer usage context. Only mentions policy restrictions but not alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files on a remote host. Wraps the find command with structured parameters so you don't have to construct find syntax manually.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Directory to search in (e.g. /var/log, /home/user) | |
| name | No | Filename pattern with wildcards (e.g. '*.log', 'config.*') | |
| type | No | File type: f=file, d=directory, l=symlink | |
| maxdepth | No | Maximum directory depth to search | |
| minsize | No | Minimum file size (e.g. '1M', '100k') | |
| maxsize | No | Maximum file size (e.g. '10M', '500k') | |
| newer | No | Reference file path -- find matches files modified more recently than this file | |
| timeout | No | Command timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the tool wraps find but omits side effects (e.g., resource intensity), return format, error handling, or security considerations (though password warning is in schema, not description).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose with no wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema), the description is too sparse. It does not explain return values, error behavior, or how results are presented. More context about the tool's behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the overall purpose; it does not augment understanding of individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search for files' and resource 'on a remote host', distinguishing it from sibling tools by mentioning it wraps the find command, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It implies usage for complex searches via find but lacks guidance on when not to use it (e.g., for simple listing, use ssh_ls). The parameter schema provides implicit context but description alone is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test Git-over-SSH authentication to a hosting provider (GitHub, GitLab, Bitbucket, etc). Verifies your SSH key is registered and working. Use this when git clone/pull/push fails with SSH errors.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Git hosting hostname (default: "github.com") | |
| user | No | SSH user for the git host (default: "git") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description clearly indicates this is a read-only diagnostic test verifying SSH key registration; no side effects mentioned but implied non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and immediate usage scenario; zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple diagnostic tool, but lacks description of output format or return values, which is especially needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions; description only adds default host value, not enhancing meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies 'Test Git-over-SSH authentication' with explicit hosting examples, distinguishing it from sibling SSH tools that are more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use this when git clone/pull/push fails with SSH errors', providing clear context; lacks explicit 'when not to use' but strong positive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the directory and output fields, which is adequate for a simple listing tool. However, it does not mention error handling (e.g., if ~/.ssh/ does not exist) or limitations (e.g., handling of subdirectories).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the tool's purpose, the second gives usage guidance. No redundant information, and the key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description effectively covers the tool's purpose, scope, and use case. It does not detail the return format, but that is predictable for a listing tool. Slightly more on error scenarios could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100% by default. The description provides useful context about what is listed (keys in ~/.ssh/ with specific attributes), adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists SSH private keys in a specific directory (~/.ssh/) and specifies the output fields (type, fingerprint, loaded status). It effectively distinguishes from sibling tools like ssh_key_load.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear use case: 'find which keys are available and which ones need to be loaded.' It implicitly suggests when to use this tool over alternatives like ssh_key_load, but does not explicitly 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.
Load an SSH private key into the running agent. Ensures the agent is running first. Use this after ssh_key_list shows a key that is not loaded.
| Name | Required | Description | Default |
|---|---|---|---|
| keyPath | Yes | Path to the SSH private key to load (e.g. ~/.ssh/id_ed25519) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states 'Ensures the agent is running first', implying a possible side effect, but does not detail failure modes, persistence, or behavior if key already loaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter. Covers purpose, prerequisite, and usage timing. Lacks mention of return values or error handling, but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the schema already describing keyPath. The description adds no new semantics beyond 'Load an SSH private key', which is redundant with the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load an SSH private key') and the resource ('into the running agent'). It distinguishes from siblings like ssh_key_list and ssh_agent_ensure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after ssh_key_list shows an unloaded key, providing clear context. It mentions ensuring the agent is running first but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a stale host key from known_hosts and re-scan the host to add the current key. Use this when you see 'Host key verification failed' errors, typically after a server has been recreated or reprovisioned.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the main behavioral trait: it removes a stale key and re-scans to add the current key. No annotations provided, so description carries the burden; it adequately describes the side effect on known_hosts without extra details on permissions or errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence explains the action, second provides usage context. Highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters, no output schema, and clear description, the tool is sufficiently described. It covers purpose, trigger, and behavior. Minor omission: could mention that it modifies the known_hosts file, but it's implied by 'remove from known_hosts'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. The description does not enhance understanding of the host or port parameters beyond what the schema provides, leading to a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: remove a stale host key and re-scan the host. It specifies the resource (known_hosts) and the verb (fix). It distinguishes from sibling tools by targeting a specific SSH issue, 'Host key verification failed'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool: when 'Host key verification failed' errors occur, typically after server reprovisioning. No explicit when-not or alternatives, but the context is clear and sufficient for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in a directory on a remote host via SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Absolute path to the remote directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the protocol (SFTP) but fails to mention authentication requirements, potential errors (e.g., directory not found, permission denied), or whether the output is a flat list or includes metadata. This is insufficient for a tool that interacts with remote systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that conveys the core functionality without extraneous words. It is front-loaded and immediately understandable, making it easy for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description omits important context: no output schema is provided, so the agent does not know the format of the listing (e.g., just names or with details). Also, no information about error handling or edge cases (e.g., nonexistent path) is given. This leaves the agent underinformed for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage), so the schema already provides meaning. The description adds no further detail beyond what is in the schema, such as the fact that 'password' is discouraged. The baseline of 3 is appropriate as the description does not compensate for any missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List files in a directory on a remote host via SFTP' is a specific verb+resource combination. It clearly states the action (list files), the target (a directory on a remote host), and the protocol (SFTP). This distinguishes it from siblings like ssh_read_file or ssh_exec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools (e.g., ssh_stat, ssh_find). There is no mention of prerequisites, authentication methods, or when not to use it. This omission reduces its usefulness for an AI agent deciding among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create 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.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Absolute path of the directory to create | |
| recursive | No | Create parent directories as needed (default: false). Like `mkdir -p`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Explains recursive creation, tolerance of existing parent dirs, and error on existing leaf. Lacks authentication details but implies SFTP use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded action. Every sentence earns its place with specific behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and full parameter coverage, description explains recursive behavior and error handling effectively. Could mention permission assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema: explains recursive like mkdir -p, notes absolute path requirement, and highlights password security. Schema already covers 100% of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action and method: 'Create a directory on a remote host via SFTP.' Distinguishes from sibling tools like ssh_delete, ssh_ls, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on recursive flag behavior and error conditions. Could explicitly recommend against using ssh_exec for mkdir, but for a dedicated tool, context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a command on multiple remote hosts in parallel. Returns results per host. Use this instead of calling ssh_exec multiple times — it's faster and shows results side by side. Subject to SSH_MCP_COMMAND_WHITELIST / SSH_MCP_COMMAND_BLACKLIST if configured (policy is checked once before fan-out).
| Name | Required | Description | Default |
|---|---|---|---|
| hosts | Yes | List of SSH hostnames or IPs | |
| command | Yes | Shell command to execute on all hosts | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| timeout | No | Command timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses parallel execution, per-host result return, and policy check before fan-out. With no annotations, this adds useful behavioral context. However, lacks details on partial failures or error handling, preventing a top score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded with purpose, then usage guidance, then behavioral note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects for a parallel execution tool (parallelism, policy, alternative to single exec). Missing explicit description of output format (e.g., how results per host are structured) and no output schema, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description does not add much beyond schema (e.g., no elaboration on hosts/command format). Since schema is comprehensive, the description's contribution is minimal, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Execute a command on multiple remote hosts in parallel'. It clearly distinguishes itself from the sibling ssh_exec by explicitly stating 'Use this instead of calling ssh_exec multiple times'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use ('Use this instead of calling ssh_exec multiple times — it's faster and shows results side by side') and mentions policy constraints (whitelist/blacklist). No explicit when-not, but the directive is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file from a remote host via SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Absolute path to the remote file. Must start with /. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without detailing authentication requirements, error handling, file size limits, or whether it returns raw content or requires a session. For a tool establishing an SFTP connection, much behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose efficiently without any fluff or redundant information. Every word serves a purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no output schema or annotations, the description is minimal. It does not explain return values, error behavior, required authentication setup (e.g., SSH keys), or how the file content is presented. The schema covers parameters but not runtime behavior, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 6 parameters with descriptions (100% coverage), so the baseline is 3. The tool description does not add extra semantics beyond what the schema already provides, but it also does not repeat information, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read', the resource 'file from a remote host', and the protocol 'SFTP', making the tool's purpose unambiguous. It contrasts with siblings like ssh_write_file (write) and ssh_download (download), though ssh_download might overlap; however, the verb 'read' implies returning file contents, which is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like ssh_download or ssh_exec with cat. With many sibling tools, explicit context on usage scenarios or exclusions would greatly help an AI agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a systemd service on a remote host. Returns whether it's active, its PID, uptime, and description. Use this instead of ssh_exec with systemctl.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| service | Yes | Systemd service name (e.g. nginx, sshd, docker) | |
| timeout | No | Command timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool performs a read-only status check via systemctl, which implies no destructive side effects. It discloses the returned data but does not detail authentication requirements or potential error conditions. However, for a simple status tool, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core function and then providing guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool, the description adequately covers purpose, output, and usage context. The absence of an output schema is compensated by listing the returned fields. Minor gaps (e.g., error handling) are acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all parameters. The description adds no new semantic information about parameters beyond the schema, but it reinforces that the tool uses systemctl for service status. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking the status of a systemd service on a remote host, and lists the returned information (active status, PID, uptime, description). It uses a specific verb ('Check') and resource ('systemd service on a remote host'), distinguishing it from sibling tools like ssh_exec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Use this instead of ssh_exec with systemctl', providing clear guidance on when to use this tool versus the sibling ssh_exec tool. This effectively differentiates the tool and gives context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a file or directory on a remote host via SFTP. Returns size, permissions (octal), uid/gid, mtime/atime, and type flags (isFile, isDirectory, isSymbolicLink). Use this instead of parsing ls -la output.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Absolute path to the remote file or directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details the exact metadata returned (e.g., permissions in octal, type flags) and mentions SFTP protocol. It does not disclose potential behaviors like symlink following or error handling, but for a straightforward stat operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences that are front-loaded with the action and key details. Every sentence adds value, with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description thoroughly explains the return values, listing all relevant fields. It is complete for a metadata retrieval tool with no complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description does not add meaning beyond the schema; it mentions no additional parameter details. Baseline score of 3 is appropriate since the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get metadata'), the resource ('file or directory on a remote host via SFTP'), and lists the specific return fields (size, permissions, uid/gid, mtime/atime, type flags). It distinguishes from parsing `ls -la` output, making 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool instead of parsing `ls -la` output, providing a clear usage scenario. However, it does not explicitly state when not to use it or compare it to sibling tools like ssh_ls, which could be a common alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the last N lines of a file on a remote host, optionally filtering by a grep pattern. Use this for reading log files instead of ssh_exec with manual tail/grep commands.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Absolute path to the file to tail | |
| lines | No | Number of lines to read from the end (default: 100). Must be a positive integer. | |
| grep | No | Case-insensitive pattern to filter lines | |
| timeout | No | Command timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits. It implies a read-only operation ('Read the last N lines') but does not state it explicitly. It lacks details on error handling, permissions, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. No wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-tail tool with no output schema, the description is adequate but incomplete. It does not describe the return value, error scenarios, or edge cases (e.g., file not found, permission denied).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds little beyond the schema: it mentions 'lines' and 'grep' but without expanding on their syntax or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read the last N lines of a file on a remote host, optionally filtering by a grep pattern.' It uses a specific verb ('Read') and resource ('file on a remote host'), and differentiates from a sibling ('Use this for reading log files instead of ssh_exec with manual tail/grep commands').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use for log files over ssh_exec, providing a clear alternative. However, it does not discuss other contexts like reading large files or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick connectivity test to an SSH host. Reports success/failure with timing and actionable error details. Lighter and faster than ssh_diagnose — use this for a quick check before running operations.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. States it tests connectivity and reports timing and error details, but lacks detail on side effects (e.g., modifying known_hosts) or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose and outcome, includes comparative guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description hints at output format (success/failure, timing, error details). Differentiates from sibling and covers key usage context; could mention authentication but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (host, port with default). Description adds no extra parameter detail, but conciseness is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states tool does a quick SSH connectivity test returning success/failure with timing and error details. Distinguishes from sibling ssh_diagnose as lighter and faster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use for quick check before operations and contrasts with ssh_diagnose. Does not explicitly list when not to use, but implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local file to a remote host via SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| localPath | Yes | Path to the local file to upload | |
| remotePath | Yes | Absolute path on the remote host |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It fails to disclose behavioral traits like authentication methods (key vs password), file overwrite behavior, error handling, or network requirements 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose without waste. It earns its place and is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too brief. It omits crucial context like what the tool returns (success/failure), file size limits, and authentication flow, leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. The description adds no extra meaning beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload a local file to a remote host via SFTP'), using a specific verb and resource. It distinguishes from sibling tools like ssh_download and ssh_write_file by specifying the direction and method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for uploading files, but does not provide explicit guidance on when to use this tool over alternatives (e.g., ssh_write_file for content-based writing) or prerequisites (e.g., SSH access). No when-not-to-use conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a file on a remote host via SFTP. Creates or overwrites the file.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH hostname or IP address | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username (default: current user) | |
| privateKeyPath | No | Path to SSH private key | |
| password | No | SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process. | |
| path | Yes | Absolute path to the remote file | |
| content | Yes | File content to write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior but only states 'write content' and 'creates or overwrites'. Missing details: authentication method, required permissions, error handling, connection retry, handling of binary content, and whether the directory must exist. The password warning in the schema is not echoed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly conveys the core function. No redundant words; every part serves a purpose. Front-loads the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 7 parameters, no annotations, and no output schema, the description is extremely brief. It fails to explain return values, error cases, or important context like security considerations (password warning from schema). The tool is more complex than the description suggests.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'write content to a file' and the resource 'on a remote host via SFTP', which distinguishes it from siblings like ssh_read_file (read), ssh_delete (delete), or ssh_exec (execute commands). The phrase 'Creates or overwrites the file' further clarifies the operation's effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs. alternatives (e.g., ssh_upload for uploading files, ssh_exec for command execution). There is no discussion of prerequisites (e.g., directory existence, SFTP availability) or when not to use it (e.g., for large files or sensitive data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.11.7ssh_read_file1 field changedInput schema / properties / path / descriptionPrevious value: -"Absolute path to the remote file"New value: +"Absolute path to the remote file. Must start with /."v0.11.0ssh_deletessh_exec1 field changedInput schema / properties / envAdded value: +{
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Environment variables to set for this command. Injected as a `KEY='value' ...` prefix; works on any sshd regardless of AcceptEnv config. Values are POSIX-single-quoted, so any byte is safe.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}ssh_find1 field changedInput schema / properties / newerAdded value: +{
+ "description": "Reference file path -- find matches files modified more recently than this file",
+ "type": "string"
+}ssh_mkdirssh_statssh_tail4 fields changedInput schema / properties / lines / descriptionPrevious value: -"Number of lines to read from the end (default: 100)"New value: +"Number of lines to read from the end (default: 100). Must be a positive integer."Input schema / properties / lines / exclusiveMinimumAdded value: +0Input schema / properties / lines / maximumAdded value: +9007199254740991Input schema / properties / lines / typePrevious value: -"number"New value: +"integer"v0.9.1ssh_agent_ensuressh_config_lookupssh_diagnose4 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / port / maximumAdded value: +65535Input schema / properties / port / minimumAdded value: +1Input schema / properties / port / typePrevious value: -"number"New value: +"integer"ssh_download5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / password / descriptionPrevious value: -"SSH password (prefer keys)"New value: +"SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process."Input schema / properties / port / maximumAdded value: +65535Input schema / properties / port / minimumAdded value: +1Input schema / properties / port / typePrevious value: -"number"New value: +"integer"ssh_exec9 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / command / descriptionPrevious value: -"Shell command to execute on the remote host"New value: +"Shell command to execute on the remote host (interpreted by the remote login shell)"Input schema / properties / password / descriptionPrevious value: -"SSH password (prefer keys)"New value: +"SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process."Input schema / properties / port / maximumAdded value: +65535Input schema / properties / port / minimumAdded value: +1Input schema / properties / port / typePrevious value: -"number"New value: +"integer"Input schema / properties / timeout / exclusiveMinimumAdded value: +0Input schema / properties / timeout / maximumAdded value: +9007199254740991Input schema / properties / timeout / typePrevious value: -"number"New value: +"integer"ssh_findssh_git_checkssh_key_listssh_key_loadssh_known_hosts_fixssh_ls5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / password / descriptionPrevious value: -"SSH password (prefer keys)"New value: +"SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process."Input schema / properties / port / maximumAdded value: +65535Input schema / properties / port / minimumAdded value: +1Input schema / properties / port / typePrevious value: -"number"New value: +"integer"ssh_multi_execssh_read_file5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / password / descriptionPrevious value: -"SSH password (prefer keys)"New value: +"SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process."Input schema / properties / port / maximumAdded value: +65535Input schema / properties / port / minimumAdded value: +1Input schema / properties / port / typePrevious value: -"number"New value: +"integer"ssh_service_statusssh_tailssh_testssh_upload5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / password / descriptionPrevious value: -"SSH password (prefer keys)"New value: +"SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process."Input schema / properties / port / maximumAdded value: +65535Input schema / properties / port / minimumAdded value: +1Input schema / properties / port / typePrevious value: -"number"New value: +"integer"ssh_write_file5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / password / descriptionPrevious value: -"SSH password (prefer keys)"New value: +"SSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process."Input schema / properties / port / maximumAdded value: +65535Input schema / properties / port / minimumAdded value: +1Input schema / properties / port / typePrevious value: -"number"New value: +"integer"v0.2.0ssh_diagnosessh_downloadssh_execssh_lsssh_read_filessh_uploadssh_write_fileEach tool has a distinct and clearly defined purpose. For example, ssh_exec, ssh_multi_exec, ssh_test, and ssh_diagnose are all different operations (single command, parallel execution, quick check, deep diagnostics). File operations like ssh_read_file, ssh_download, and ssh_delete are well-separated. No two tools overlap in functionality.
All tools follow the consistent pattern of `ssh_` prefix followed by a descriptive verb or verb_noun phrase (e.g., ssh_exec, ssh_key_list, ssh_known_hosts_fix). Naming is uniform in snake_case and logical, making it easy to predict tool names.
21 tools is well-scoped for an SSH server covering connectivity, file transfer, command execution, key management, diagnostics, and service checks. Each tool addresses a specific need without bloat or redundancy.
The tool set covers a comprehensive range of SSH operations including file manipulation, command execution, diagnostics, key/agent management, and git auth testing. A notable omission is port forwarding/tunneling support, which is a common SSH use case. Aside from that, the surface is very complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Remote shell and detached long-running jobs on your own machines — no SSH, open ports or VPN.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/YawLabs/ssh-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
