ssh-bridge-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SSH_BRIDGE_KEY_PATH | No | Path to a private key, if you use key auth instead | |
| SSH_BRIDGE_PASSWORD | No | Password used by ssh_connect when no key is configured | |
| SSH_BRIDGE_HTTP_HOST | No | Bind address in HTTP mode | 127.0.0.1 |
| SSH_BRIDGE_HTTP_PORT | No | Bind port in HTTP mode | 8000 |
| SSH_BRIDGE_TRANSPORT | No | stdio (default, local process) or streamable-http (network, for claude.ai web) | stdio |
| SSH_BRIDGE_HTTP_TOKEN | No | Required in HTTP mode. Bearer token clients must send; server refuses to start without it in streamable-http mode | |
| SSH_BRIDGE_ALLOWED_HOSTS | No | Comma-separated allowlist of hosts this server may connect to (recommended once you're not just testing) | |
| SSH_BRIDGE_DENY_PATTERNS | No | Comma-separated glob patterns of commands to always block (ships with a small default denylist) | |
| SSH_BRIDGE_KEY_PASSPHRASE | No | Passphrase for that key, if any | |
| SSH_BRIDGE_STRICT_HOST_KEY | No | Set to '1' to require the host key already be in known_hosts instead of auto-trusting on first connect | |
| SSH_BRIDGE_MAX_OUTPUT_CHARS | No | Truncate command output beyond this length | 20000 |
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_connectA | Open an SSH session to a remote host and return a session_id to use with the other ssh_* tools. Credentials are resolved in this order:
Prefer leaving password/key_path unset and configuring env vars instead — that way the secret never appears in the conversation. |
| ssh_execA | Run a shell command on the remote host over an existing session and
return its stdout, stderr, and exit code. Output is truncated if very
large. Not a persistent shell — each call is a fresh |
| ssh_read_fileA | Read a text file from the remote host via SFTP. |
| ssh_write_fileB | Write text content to a file on the remote host via SFTP, overwriting it. |
| ssh_list_sessionsA | List currently open SSH sessions (host/user/port), by session_id. |
| ssh_disconnectA | Close an SSH session and free its resources. |
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 6 tools
Each tool maps to a distinct operation: session creation, command execution, file read, file write, session listing, and session teardown. There is no meaningful overlap between executing commands and transferring files via SFTP. An agent can reliably choose the right tool based on the intended action.
All tools share the ssh_ prefix and follow a consistent verb-based naming pattern: connect, exec, read_file, write_file, list_sessions, disconnect. The snake_case convention is uniform and predictable.
Six tools is well-scoped for an SSH bridge server. Each tool covers an essential part of the session lifecycle or remote interaction without unnecessary redundancy.
The core SSH workflow is well covered: connect, execute commands, read/write text files, list sessions, and disconnect. Minor gaps such as file deletion, directory listing, or binary transfer are absent, but they do not hinder typical bridge usage.