ssh-hop
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SSH_HOP_HOME | No | Directory for audit logs and known_hosts. Defaults to ~/.ssh-hop. | |
| SSH_HOP_HOSTS | No | Path to the hosts.json configuration file. Overrides the default search order (defaults to ~/.ssh-hop/hosts.json). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ssh_list_hostsA | List the remote hosts reachable through this server. Call this first whenever you need to touch a remote machine, to learn valid aliases and each host's permissions. Only aliases and descriptions are returned - never addresses or credentials. |
| ssh_probeA | Test connectivity to a host and return its identity (uname, uptime, id) plus round-trip latency. Use to diagnose 'cannot connect' problems before running real commands. |
| ssh_runA | Execute a shell command on a remote host and return stdout, stderr and the exit code. Use for inspecting state (logs, processes, ports, containers, service status) and for changing it (deploy, restart, edit). Prefer one command per call; chain with && when steps must be ordered. Set background=true for long-running or daemonizing commands so the call returns at once. Each host has its own allowCommands/denyCommands rules; a refusal names the rule that blocked it. |
| ssh_run_policyA | Check whether a command would be allowed on a host, WITHOUT running it. Returns the rule that matched. Use before a risky or unfamiliar command, or when a previous command was refused and you want to know why. |
| ssh_run_manyA | Run the same command across several hosts in parallel and return one result per host. Use to compare versions, check a service fleet-wide, restart several boxes, or survey disk usage. Each host applies its own allowCommands/denyCommands, so one host may be refused while others run; per-host status is reported rather than failing the whole call. |
| sftp_uploadA | Upload a local file or directory to a remote host over SFTP. Use to ship code, config or binaries before running deploy commands. remotePath must be absolute; localPath is any readable local path. If the host sets uploadRoots, the remote path must sit inside one. |
| sftp_downloadA | Download a remote file or directory to the local machine over SFTP. Use to pull logs, config or artifacts for offline analysis. remotePath and localPath are both plain paths; if the host sets downloadRoots/localRoots, each must sit inside its list. |
| sftp_listA | List a directory on a remote host, or stat a single remote file. Use to check whether a deployment landed, inspect permissions, or find log files before downloading them. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct action: listing hosts, probing connectivity, checking policy, running commands (single or multiple), and SFTP upload/download/list. Boundaries are clear from descriptions; no two tools appear to do the same thing. An agent can confidently select the right tool for a given task.
Tool names follow a predictable pattern: ssh_ prefix for SSH operations and sftp_ prefix for file transfer operations, with consistent verb_noun or verb phrasing (list_hosts, probe, run_policy, run, run_many, upload, download, list). The subdomain prefixes aid grouping without breaking consistency. No mixed conventions or vague verbs.
Eight tools are well-scoped for an SSH/SFTP hop server, covering host discovery, connectivity testing, policy validation, command execution, and file transfer. Each tool earns its place, and the count is neither bloated nor thin. The set is focused on the core workflows of remote access and transfer.
The surface covers the essential lifecycle: list hosts, probe, policy check, run, run_many, and SFTP upload/download/list. Minor gaps exist (e.g., no explicit sftp_delete or sftp_mkdir), but agents can work around these by using ssh_run for filesystem operations if permitted. No critical dead ends for the stated purpose.