Skip to main content
Glama

connect_ssh

Open a persistent SSH connection to a remote host and return a session ID for running commands. Supports password or key-based authentication and captures the server's welcome banner.

Instructions

Opens a persistent SSH connection to a REMOTE host and returns a session_id.
The connection stays open across tool calls until closed with `disconnect`;
drive it with `execute`. Host keys are auto-accepted (no prompt).

WHEN TO USE:
- Use this for a shell on a remote host. For a shell on the LOCAL machine
  running this server, use `create_local` instead.
- Reuse an existing session_id rather than reconnecting per command.

AUTHENTICATION (key-based recommended):
- Password: pass `username` + `password`.
- Key: pass `username` + `key_filepath` (absolute path). If both a password
  and a key are given, the key is tried first.

Captures the MOTD/welcome banner for up to `banner_timeout` seconds. Raises
on authentication failure, hostname/DNS errors, or connection timeout.

Returns a dict:
    - session_id: identifier for this connection (pass to `execute`).
    - banner: the server's MOTD, or "" if none arrived before banner_timeout.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostYesThe hostname or IP address of the SSH server to connect to (e.g., '192.168.1.10' or 'example.com')
portNoThe port number of the SSH server (default is 22)
usernameNoOptional username for authentication. If omitted, the connection will use SSH agent or system defaults
passwordNoOptional password for password-based authentication. Omit if using key-based authentication
key_filepathNoOptional absolute path to a private key file for key-based auth; must be readable by the server process. If both this and password are supplied, the key is attempted first
banner_timeoutNoThe timeout in seconds to wait for the MOTD/welcome banner after the connection opens
Behavior5/5

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

Beyond annotations (which only set hints), the description reveals key behaviors: persistent session, auto-accept host keys, banner capture with timeout, and error conditions (auth failure, DNS errors, timeout). This adds significant context for safe usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Well-structured with clear sections (purpose, when to use, authentication, behavior, return value). Each sentence earns its place; no redundant or vague phrasing. Front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, multiple auth methods, session management), the description covers all necessary aspects: how to connect, auth options, banner handling, error scenarios, and session lifecycle. No missing information given that output schema is absent but return dict is explained.

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

Parameters4/5

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

Input schema covers all 6 parameters with high-quality descriptions (100% coverage). The description adds extra clarity about authentication priority: 'If both a password and a key are given, the key is tried first.' This is a meaningful addition beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Opens a persistent SSH connection to a REMOTE host and returns a session_id.' It uses a specific verb ('opens') and resource ('SSH connection'), distinguishing it from sibling 'create_local' which is for local shells.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when to use: 'Use this for a shell on a remote host. For a shell on the LOCAL machine... use `create_local` instead.' Also advises to reuse existing session_ids and explains authentication scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/QiuwenZheng/interminal'

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