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., "@my-mcp-ssh connect to 192.168.1.100 and run 'uptime'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) based SSH connection tool that allows large language models to securely connect to remote servers via SSH and perform file operations through the MCP protocol.
SSH Connection Management: Connect to remote SSH servers
Command Execution: Execute commands on remote servers
File Transfer: Upload and download files
Session Management: Maintain and close SSH sessions
Related MCP server: ssh-client-mcp-server
Python >= 3.12
uv package manager
# Clone the project
git clone https://github.com/ffpy/my-mcp-ssh.git
# Enter the project directory
cd my-mcp-ssh
# Install dependencies
uv sync{
"mcpServers": {
"my-mcp-ssh": {
"command": "uv",
"args": [
"--directory",
"<your_path>/my-mcp-ssh",
"run",
"src/main.py"
],
"env": {}
}
}
}Environment variables provide default values for SSH connections, useful when frequently connecting to the same server or in automated environments:
SSH_HOST: SSH server hostname or IP address
SSH_PORT: SSH server port
SSH_USERNAME: SSH username
SSH_PASSWORD: SSH password (if using password authentication)
SSH_KEY_PATH: SSH private key file path (if using key authentication)
SSH_KEY_PASSPHRASE: SSH private key passphrase (if needed)
When to use SSH environment variables:
Repeated connections: When connecting to the same server multiple times
CI/CD pipelines: For automated deployment scripts
Development environments: Set defaults for your commonly used servers
Container deployments: Configure defaults without modifying code
Note: Parameters passed to the connect tool always override environment variables.
Additional server behavior can be configured:
SESSION_TIMEOUT: Session timeout in minutes, default is 30 minutes
MAX_OUTPUT_LENGTH: Maximum command output length in characters, default is 5000 characters
For better security, you can store SSH credentials in a local configuration file instead of passing passwords as parameters.
Copy the example file:
cp ssh-credentials.json.example ssh-credentials.jsonEdit ssh-credentials.json with your actual credentials:
{
"root@192.168.1.100": "your_password",
"admin@web-[0-9].example.com": "web_password",
"deploy@server-{dev,test,staging}.company.com": "deploy_password",
"admin@*.internal.network": "internal_password"
}Supported Patterns:
* - matches any characters
? - matches single character
[0-9] - matches any digit
{dev,test,staging} - matches any of the listed options
Authentication Priority Order:
Parameters passed to connect tool (password, key_path)
Exact match in credentials file (username@host)
Pattern match in credentials file (wildcards)
Environment variable password (SSH_PASSWORD)
Environment variable key (SSH_KEY_PATH)
Default SSH key (~/.ssh/id_rsa if exists)
Security:
File permissions are automatically set to 600 (owner read/write only)
The file is added to .gitignore to prevent accidental commits
Note:
Credential file changes take effect immediately without server restart
The file is read fresh on each connection attempt
Connect to an SSH server
Parameters:
host: SSH server hostname or IP address (optional)
port: SSH server port (optional, default 22)
username: SSH username (optional)
password: SSH password for authentication (optional)
key_path: SSH private key file path for authentication (optional)
key_passphrase: SSH private key passphrase if needed (optional)
Disconnect from an SSH session
Parameters:
session_id: The session ID to disconnect
List all active SSH sessions
Parameters:
None
Execute a command on the SSH server
Parameters:
session_id: Session ID
command: Command to execute
stdin: Input string to provide to the command, default is empty
timeout: Command timeout in seconds, default is 60 seconds
Upload a file to the SSH server
Parameters:
session_id: Session ID
local_path: Local file path
remote_path: Remote file path
Download a file from the SSH server
Parameters:
session_id: Session ID
remote_path: Remote file path
local_path: Local file path
Run ./inspector.sh for online debugging
my-mcp-ssh is licensed under the Apache License, Version 2.0
Connect to SSH server
Args:
host: SSH server hostname or IP address (optional)
port: SSH server port (optional, default 22)
username: SSH username (optional)
password: SSH password for authentication (optional)
key_path: SSH private key file path for authentication (optional)
key_passphrase: SSH private key passphrase if needed (optional)
Returns:
Connection status
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| port | No | ||
| key_path | No | ||
| password | No | ||
| username | No | ||
| key_passphrase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It lists authentication methods (password/key) and says it returns connection status, but does not explain session lifecycle, side effects, or failure modes.
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 organized into an Args list and a Returns line, making it easy to scan. It is appropriately sized for the number of parameters, though it could be tightened by removing the word 'optional' repetition.
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 six parameters and no output schema, the description covers the parameters and return status adequately. However, it lacks context on connection behavior (e.g., persistent sessions, timeouts, or how to use the returned status).
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 0%, and the description fully compensates by listing all six parameters with clear explanations of each (host, port, username, password, key_path, key_passphrase). This provides essential meaning beyond the bare 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 'Connect to SSH server', using a specific verb and resource. It naturally distinguishes itself from sibling tools like disconnect, execute, and list_sessions.
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 by listing connection parameters and return status, but it does not explicitly state when to use this tool over alternatives or mention preconditions like needing an existing session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from SSH server
Args:
session_id: Session ID to disconnect
Returns:
Disconnection status
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions returning a disconnection status but fails to disclose potential side effects such as terminating the session, closing active channels, or behavior when the session ID is invalid.
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 appropriately brief and front-loaded with the purpose, followed by a structured Args/Returns format. It contains no wasted words, though it could include more detail in other dimensions.
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, the description includes a return status but lacks behavioral context and usage guidance. Given the absence of annotations and output schema, the agent has limited information about the tool's side effects and lifecycle implications.
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 description merely restates the parameter name ('session_id: Session ID to disconnect') without adding meaningful context beyond the schema. It does not explain where to obtain the session ID or any constraints on its format.
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 ('Disconnect from SSH server') with a specific verb and resource, making it easy to distinguish from sibling tools like connect, execute, and list_sessions.
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 purpose implies the tool should be used to end an SSH session, but there is no explicit guidance on when to use it versus alternatives or prerequisites like having an active session. The context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download file from SSH server
Args:
session_id: Session ID
remote_path: Remote file path
local_path: Local file path
Returns:
Dictionary containing download status information
| Name | Required | Description | Default |
|---|---|---|---|
| local_path | Yes | ||
| session_id | Yes | ||
| remote_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does not mention potential side effects (e.g., overwriting existing local files), error conditions, or access requirements. The 'Returns' line is vague and adds no operational detail.
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 concise and uses a clear Args/Returns structure, but it is thin and the Returns section is uninformative ('Dictionary containing download status information'). It is not bloated, yet it under-delivers on substance.
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 has no output schema and no annotations, and the description does not explain what the returned dictionary contains, how to verify success, or how this tool relates to 'upload'. While the tool is simple, the missing context leaves the agent uncertain about invocation and result handling.
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 0%, so the description must compensate. However, it merely restates parameter names with generic descriptors ('Session ID', 'Remote file path', 'Local file path') that add little beyond the schema's own titles. No constraints, formats, or relationships are explained.
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 states 'Download file from SSH server' with clear verb and resource. The Args section clarifies the direction (remote to local) via 'remote_path' and 'local_path', distinguishing it from the sibling 'upload' tool.
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. There is no mention of prerequisites (e.g., active session), nor any exclusion or comparison with the sibling 'upload' tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute command on SSH server
Args:
session_id: Session ID
command: Command to execute
stdin: Input string to provide to the command, defaults to None
timeout: Command timeout in seconds, defaults to 60 seconds
Returns:
Command output (stdout and stderr) and exit status
| Name | Required | Description | Default |
|---|---|---|---|
| stdin | No | ||
| command | Yes | ||
| timeout | No | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core behavior (executing a command), the return format (stdout/stderr and exit status), and default timeout. However, it does not warn about potential destructive side effects or prerequisites like an active session, which is a significant gap for an execution tool.
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 efficiently structured as a docstring with Args and Returns sections. Every line adds value, with no redundant information and clear separation of parameter details.
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 the tool's purpose, parameters, and return value well. Missing usage prerequisites (e.g., active session) and safety warnings, but for a straightforward execution tool with a simple schema, it is largely complete.
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?
Input schema has 0% description coverage, so the description fully compensates by explaining all four parameters with purpose and defaults. It adds meaningful context like 'input string to provide' and 'timeout in seconds' beyond what the schema offers.
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 states 'Execute command on SSH server' with a specific verb and resource. Clearly distinguishes from sibling tools like connect, disconnect, upload, and download, which handle session management and file transfer.
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 clearly implies when to use this tool: when you need to run a command on an existing SSH session. It provides concrete context (session_id, command, timeout) but does not explicitly exclude alternatives or 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.
List all active SSH sessions
Returns:
List containing information about all sessions
| 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 only says it lists sessions and returns a list of information, but does not disclose whether this is a read-only operation, any side effects, authentication requirements, or what specific information is included beyond 'information'. This is minimal and leaves the agent uncertain about the tool's behavior.
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 concise, front-loaded with the action, and every sentence earns its place. The 'Returns' line is somewhat redundant but not harmful, and the overall structure is clear and efficient.
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 zero-parameter tool, the description is adequate but leaves gaps. It does not explain what 'information' is included in the returned list, and without an output schema, this is a notable omission. It also lacks usage context relative to sibling tools, making the description incomplete for an agent trying to decide when to invoke it.
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?
This tool has zero parameters, so the schema provides no information to add value. The description correctly does not need to detail parameters, and a baseline of 4 is appropriate for a parameterless tool.
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 states a specific verb ('List') and resource ('all active SSH sessions'), making it completely clear what the tool does. It is distinct from sibling tools which perform actions like connect, disconnect, execute, upload, and download.
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, such as needing an active connection, or whether to use this before connecting or after sessions are established. The description simply states what it does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload file to SSH server
Args:
session_id: Session ID
local_path: Local file path
remote_path: Remote file path
Returns:
Dictionary containing upload status information
| Name | Required | Description | Default |
|---|---|---|---|
| local_path | Yes | ||
| session_id | Yes | ||
| remote_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states that it uploads a file and returns a dictionary, but omits critical traits such as whether the remote file is overwritten, whether directories are created, authentication requirements, or error handling. This is insufficient for a mutation tool.
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 concise and well-structured with clear Args and Returns sections. Every sentence earns its place, though the parameter descriptions could be more substantive. Overall, it is appropriately sized and 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?
The tool is simple but the description omits essential context such as the requirement of an active session (prerequisite from connect), potential side effects, and error behavior. With no annotations and no output schema, the description is incomplete for an AI agent to use reliably.
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 Args section lists all three parameters but the descriptions are tautological (e.g., 'local_path: Local file path'), adding little meaning beyond the parameter names. Since the schema has 0% description coverage, the tool description should compensate but does not provide any additional detail about formats, constraints, or behavior.
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 and resource: 'Upload file to SSH server'. This is a specific verb+resource construction that unambiguously distinguishes it from siblings like download and execute.
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 that a session must be active (via connect) or that download is the counterpart for retrieval. The purpose is implied but no explicit usage context is given.
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.1.0connectdisconnectdownloadexecutelist_sessionsuploadEach tool targets a distinct action: connect/disconnect manage sessions, list_sessions enumerates them, execute runs commands, and upload/download transfer files. There is no overlap or ambiguity between tool purposes.
All tool names follow a clear imperative verb style, using lowercase with underscores. The names are concise and predictable, with list_sessions being the only verb_noun form, which is appropriate for a listing operation.
The server provides 6 tools, which is well-scoped for an SSH MCP server. Each tool serves a core function (session management, command execution, file transfer) without unnecessary bloat, fitting the typical 3-15 tool range.
The tool surface covers the full lifecycle of SSH interactions: connect, disconnect, session listing, command execution, and file upload/download. No obvious gaps exist for standard SSH usage, making the set complete for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server for AI dialogue using various LLM models via AceDataCloud
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ffpy/my-mcp-ssh'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
