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 connect to my server 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.
An MCP (Model Context Protocol) server that enables LLMs to interact with remote servers via SSH functionality including command execution, file upload/download, and directory listing.
Connection Management: Establish and manage multiple SSH sessions
Command Execution: Run shell commands on remote servers with full output capture
File Operations: Upload and download files via SFTP with optional permissions
Directory Listing: Browse remote directories with file metadata (size, type, timestamps)
Security: Command injection prevention, proper credential handling, Pydantic validation
Flexible Authentication: Support for both password and SSH key authentication
Related MCP server: MCP SSH Server
pip install ssh-mcp-newPython 3.10 or higher
Dependencies automatically installed via pip
mcp >= 1.0.0
pydantic >= 2.0.0
paramiko >= 3.0.0
ssh-mcptips: you can also add python scripts to your path env, it's all up to you.
"mcpServers": {
"ssh-mcp": {
"command": "C:\\Users\\DELL\\AppData\\Local\\Packages\\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\\LocalCache\\local-packages\\Python311\\Scripts\\ssh-mcp.exe",
"args": [],
"env": {}
}
},The MCP Inspector allows you to test the server interactively:
npx @modelcontextprotocol/inspector python -m ssh_mcpTool | Description |
| Establish SSH connection to remote server |
| Check status of SSH sessions |
| Execute commands on remote server |
| Upload files to remote server |
| Download files from remote server |
| List files in remote directory |
| Close SSH connection |
Using password authentication:
{
"host": "192.168.1.100",
"port": 22,
"username": "admin",
"password": "your_password"
}Using SSH key authentication:
{
"host": "192.168.1.100",
"port": 22,
"username": "admin",
"private_key_path": "/home/user/.ssh/id_rsa",
"private_key_password": "key_passphrase" # optional for encrypted keys
}{
"session_id": "admin@192.168.1.100:22",
"command": "ls -la /var/log",
"working_directory": "/var/log", # optional
"response_format": "markdown" // "json" for machine-readable output
}{
"session_id": "admin@192.168.1.100:22",
"local_path": "./config.json",
"remote_path": "/tmp/config.json",
"file_mode": 511 // 0o644 in octal
}{
"session_id": "admin@192.168.1.100:22",
"remote_path": "/var/log/syslog",
"local_path": "./syslog",
"overwrite": false
}{
"session_id": "admin@192.168.1.100:22",
"remote_path": "/tmp",
"show_hidden": false,
"response_format": "markdown"
}{
"session_id": "admin@192.168.1.100:22"
}Multiple concurrent SSH sessions are supported. Each session is identified by a session_id:
Auto-generated as {username}@{host}:{port} if not specified
Can be explicitly provided for custom naming
Sessions persist as long as the server is running
The server supports two authentication methods:
Password authentication:
Provide password parameter in ssh_connect
Suitable for quick testing or environments where keys are not available
SSH Key authentication (recommended for production):
Provide private_key_path parameter pointing to your private key file
Optionally provide private_key_password for encrypted keys
More secure than password-based authentication
Tools that return structured data support two formats:
markdown (default): Human-readable output with formatting
json: Machine-readable structured data
# Clone the repository
git clone https://github.com/ifindv/ssh-mcp.git
cd ssh-mcp
# Install in development mode
pip install -e ".[dev]"
# Run tests (when available)
pytest
# Format code
black ssh_mcp/
# Type checking
mypy ssh_mcp/This project uses:
Black for code formatting (line length: 100)
MyPy for static type checking
PEP 8 for style guidelines
Command injection prevention: Invalid characters are filtered from command inputs
Host key verification: Uses AutoAddPolicy by default. For production environments, configure proper host key verification
Credential handling: Credentials are passed via parameters and are not stored persistently
Input validation: All inputs are validated using Pydantic models
Sensitive data: Passwords and private key passwords are marked as sensitive in the schema
Verify SSH service is running on the target server
Check firewall settings and network connectivity
Ensure the correct port is specified (default: 22)
Verify username and password/SSH key are correct
Check that the private key file exists and has correct permissions
Ensure the SSH key is added to the server's ~/.ssh/authorized_keys file
Check network connectivity and latency
Increase the timeout parameter value
Verify that the server is responsive and not overloaded
Ensure user has appropriate permissions on the remote server
Check file and directory permissions for SFTP operations
Verify SSH key permissions (typically 600 for private keys)
Contributions are welcome! Please read our contributing guidelines and submit pull requests to our repository.
This project is licensed under the MIT License - see the LICENSE file for details.
Issues: GitHub Issues
Documentation: GitHub Wiki
Establish an SSH connection to a remote server.
This tool creates a new SSH session that can be used for subsequent operations like command execution, file upload/download, and directory listing.
Args: params (ConnectInput): Validated input parameters containing: - host (str): Remote server hostname or IP address (e.g., "192.168.1.100", "server.example.com") - port (int): SSH port number, default 22, range 1-65535 - username (str): SSH username for authentication - password (Optional[str]): Password for authentication (alternative to private_key_path) - private_key_path (Optional[str]): Path to SSH private key file (alternative to password) - private_key_password (Optional[str]): Password for encrypted private key - timeout (int): Connection timeout in seconds, default 30, range 1-300 - session_id (Optional[str]): Session identifier, auto-generated if omitted
Returns: str: Session ID for the established connection or error message
Examples: - Use when: "Connect to server 192.168.1.100 with username admin" -> params with host="192.168.1.100", username="admin" - Use when: "Connect using SSH key" -> params with private_key_path="/path/to/key" - Don't use when: Session already exists (use ssh_status to check) - Don't use when: Need to execute multiple commands to different servers (create separate sessions)
Error Handling: - Returns error if authentication fails (check credentials) - Returns error if host is unreachable (check network) - Returns error if port is invalid or service not running
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses session creation, return value (session ID or error), and error conditions (auth failure, unreachable host). Complements annotations (readOnlyHint=false, destructiveHint=false) with additional context.
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?
Well-structured with sections for purpose, args, returns, examples, and error handling. Every sentence is informative, and the description is appropriately concise for a complex tool.
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 all necessary aspects: purpose, parameters, return values, error handling, and usage boundaries. References sibling tools and provides complete guidance for an SSH connection 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?
The 'Args' section fully explains each parameter, including defaults, constraints, and relationships (e.g., password as alternative to private_key_path). Adds value beyond schema descriptions with examples and ranges.
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 'Establish an SSH connection to a remote server' and explains it creates a session for subsequent operations, distinguishing it from sibling tools like ssh_disconnect or ssh_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?
Explicit 'Use when' and 'Don't use when' examples are provided, including alternatives like ssh_status to check existing sessions and guidance for multiple servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close an SSH connection session.
This tool terminates an SSH session and frees associated resources.
Args: params (DisconnectInput): Validated input parameters containing: - session_id (str): SSH session identifier to close
Returns: str: Disconnection confirmation
Examples: - Use when: "Close SSH connection to server" -> params with session_id="admin@192.168.1.100:22" - Use when: "Done working with server, disconnect" -> params with session_id (from ssh_connect) - Don't use when: Session doesn't exist (ssh_status will show this) - Don't use when: Need to continue working with the server
Error Handling: - Returns "Error: Session not found" if session_id is invalid - Returns success even if session was already closed
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and not destructive. Description adds that it terminates and frees resources, and returns success even if already closed, aligning with annotations. Slight gap: doesn't detail what 'frees associated resources' means, but overall good.
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?
Concise with clear sections (overview, args, returns, examples, error handling). Every sentence adds value, and the structure is front-loaded with the core 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?
For a simple one-parameter tool, the description covers purpose, usage, error handling, idempotency, and return format. Output schema exists but description adequately summarizes the return value.
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 only parameter, session_id, has a description in the schema ('SSH session identifier to close') which is repeated verbatim in the description. No additional semantics or constraints are provided beyond the schema, so baseline 3 applies.
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 'Close an SSH connection session' and elaborates that it terminates an SSH session and frees resources. It uses specific verb-resource pairing and distinguishes from sibling tools like ssh_connect, ssh_execute, 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 explicit when-to-use and when-not-to-use examples, such as 'Use when: Close SSH connection to server' and 'Don't use when: Session doesn't exist' or 'Need to continue working with the server.' Also covers error handling and idempotency.
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 the remote server to the local machine via SFTP.
This tool transfers a file from the connected SSH server to the local machine.
Args: params (DownloadFileInput): Validated input parameters containing: - session_id (str): SSH session identifier from ssh_connect - remote_path (str): Path to remote file to download (e.g., "/var/log/syslog") - local_path (str): Destination path for downloaded file (e.g., "./syslog", "/tmp/downloaded.log") - overwrite (bool): Overwrite local file if it exists, default False
Returns: str: Download confirmation with file size and paths
Examples: - Use when: "Download /var/log/syslog to local machine" -> params with remote_path="/var/log/syslog", local_path="./syslog" - Use when: "Get config file from server" -> params with remote_path="/etc/app/config", local_path="config" - Don't use when: Local file exists and overwrite=False - Don't use when: Need to download multiple files (call this tool multiple times)
Error Handling: - Returns "Error: Session not found" if session_id is invalid - Returns error if remote file doesn't exist - Returns error if local file exists and overwrite=False - Returns error if local directory doesn't have write permissions
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds error handling details (session not found, file exists, permissions) and overwrite behavior, enriching transparency. However, the idempotentHint is not fully reinforced by 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 well-structured with sections (Args, Returns, Examples, Error Handling), front-loaded with the main purpose, and every sentence adds value without verbosity.
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 tool's simplicity, the description covers the main use case, error conditions, return value, and even provides multiple examples. Output schema existence is noted, and the description complements it with return format details.
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 high (each parameter has a description). The description adds examples (e.g., '/var/log/syslog') and context for parameters, going beyond the schema. Baseline 3, plus extra value gives 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 clearly states 'Download a file from the remote server to the local machine via SFTP', which is a specific verb+resource. It differentiates from siblings like ssh_upload_file (upload) and ssh_list_files (list).
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 explicit 'Use when' and 'Don't use when' examples, mentions multiple calls for multiple files, and lists error conditions. This provides strong guidance on when to use this tool vs alternatives.
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 the remote server via SSH.
This tool runs a shell command on the connected server and captures stdout, stderr, and exit code. The command runs in a non-interactive shell.
Args: params (ExecuteInput): Validated input parameters containing: - session_id (str): SSH session identifier from ssh_connect - command (str): Command to execute on remote server (e.g., "ls -la", "whoami", "cat /etc/os-release") - working_directory (Optional[str]): Working directory for command execution (e.g., "/var/log") - timeout (int): Execution timeout in seconds, default 30, range 1-600 - response_format (ResponseFormat): Output format (markdown or json)
Returns: str: Command execution result with stdout, stderr, and exit code
Examples: - Use when: "Check what Linux distribution is running" -> params with command="cat /etc/os-release" - Use when: "List files in /var/log" -> params with command="ls -la /var/log" - Use when: "Check disk usage" -> params with command="df -h" - Don't use when: Need interactive commands (e.g., vim, top - use non-interactive alternatives) - Don't use when: Need to run multiple commands in sequence (execute tools separately)
Error Handling: - Returns "Error: Session not found" if session_id is invalid - Returns execution result with non-zero exit code if command fails - Returns timeout error if command exceeds timeout limit
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and destructiveHint=true, and the description adds context about non-interactive shell execution and error handling (session not found, timeout). No contradiction with annotations.
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?
Well-structured with sections (Args, Returns, Examples, Error Handling). Some redundancy could be trimmed, but overall efficient for the information provided.
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 nested parameter structure and presence of an output schema, the description covers purpose, parameters, usage guidelines, error handling, and output format comprehensively.
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?
Although schema description coverage is 0%, the tool description clearly explains each parameter (session_id, command, working_directory, timeout, response_format) with examples and constraints (e.g., timeout range 1-600).
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 the tool executes a command on a remote server via SSH, capturing stdout, stderr, and exit code. Distinguishes from sibling tools like ssh_connect and ssh_download_file by focusing on 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?
Provides specific when-to-use examples (e.g., 'Check what Linux distribution is running') and explicit when-not-to-use cases (interactive commands, sequential commands). Also notes the prerequisite of a session_id from ssh_connect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in a remote directory via SFTP.
This tool provides a directory listing with file metadata including size, type, and modification time.
Args: params (ListFilesInput): Validated input parameters containing: - session_id (str): SSH session identifier from ssh_connect - remote_path (str): Path to remote directory to list (e.g., "/var/log", "~", "/tmp") - show_hidden (bool): Show hidden files (starting with .), default False - response_format (ResponseFormat): Output format (markdown or json)
Returns: str: Directory listing with file details
Examples: - Use when: "List files in /var/log" -> params with remote_path="/var/log" - Use when: "Show all files including hidden ones in home directory" -> params with remote_path="~", show_hidden=True - Use when: "Check what's in /tmp" -> params with remote_path="/tmp" - Don't use when: Need to list files on local machine (use local filesystem instead)
Error Handling: - Returns "Error: Session not found" if session_id is invalid - Returns error if remote directory doesn't exist - Returns error if directory is not readable due to permissions
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds behavioral context by listing error cases (invalid session, missing directory, permissions) and mentioning return of file metadata. This goes beyond annotations without contradicting them.
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 well-structured with sections for args, returns, examples, and error handling, but it is slightly verbose. Every sentence adds value, but a minor trim could improve conciseness.
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 tool's complexity (SSH session, multiple parameters, output schema exists), the description is complete. It covers all necessary aspects: purpose, parameters, examples, error handling, and output format. The presence of an output schema further reduces the need to explain return values.
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 adds meaning beyond the input schema by explaining session_id as 'from ssh_connect', providing examples for remote_path, and clarifying show_hidden default. Although schema coverage is technically low, the description compensates with detailed parameter explanations.
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 files and directories in a remote directory via SFTP, specifying the verb 'list' and the resource 'remote directory'. It distinguishes itself from siblings like ssh_download_file and ssh_execute by focusing on listing.
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 explicit examples of when to use the tool (e.g., 'List files in /var/log') and explicitly states when not to use it ('Don't use when: Need to list files on local machine (use local filesystem instead)'). This provides clear guidance on appropriate context.
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 SSH connection sessions.
This tool reports which SSH sessions are active and their connection details.
Args: params (StatusInput): Validated input parameters containing: - session_id (Optional[str]): Specific session to check, or None to list all active sessions
Returns: str: JSON-formatted status information for active sessions
Examples: - Use when: "Check all active SSH connections" -> params with session_id=None - Use when: "Verify if connection to server is still active" -> params with specific session_id - Don't use when: Need to execute commands (use ssh_execute instead)
Error Handling: - Returns "No active sessions" if no connections are established - Returns specific session info if session_id is provided and valid
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds error handling details like 'Returns No active sessions if no connections are established', which is useful context beyond annotations.
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?
Concise with clear sections (Args, Returns, Examples, Error Handling). Every sentence is informative. 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?
Given good annotations and sibling context, description provides necessary info. Could add more detail on the structure of the returned JSON, but error handling examples are helpful.
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% due to nested $ref, but description explains the params parameter containing session_id (optional), adding meaning that schema's definition alone might not capture.
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 states 'Check the status of SSH connection sessions' with specific verb and resource. Distinguishes from sibling ssh_execute by saying not to use when commands needed.
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 when-to-use examples ('Check all active SSH connections', 'Verify if connection to server is still active') and a when-not-to-use example with alternative (use ssh_execute instead).
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 the remote server via SFTP.
This tool transfers a file from the local machine to the connected SSH server.
Args: params (UploadFileInput): Validated input parameters containing: - session_id (str): SSH session identifier from ssh_connect - local_path (str): Path to local file to upload (e.g., "./config.json", "/tmp/data.csv") - remote_path (str): Destination path on remote server (e.g., "/tmp/config.json", "~/mydata.csv") - file_mode (int): File permissions in octal, default 0o644 (rw-r--r--)
Returns: str: Upload confirmation with file size and paths
Examples: - Use when: "Upload config.json to /tmp/" -> params with local_path="./config.json", remote_path="/tmp/config.json" - Use when: "Transfer script to home directory" -> params with local_path="script.sh", remote_path="~/script.sh" - Don't use when: Remote file already exists (use ssh_execute with rm first or set file_mode accordingly) - Don't use when: Need to upload multiple files (call this tool multiple times)
Error Handling: - Returns "Error: Session not found" if session_id is invalid - Returns error if local file doesn't exist - Returns error if remote directory doesn't have write permissions - Returns error if file size is too large for available bandwidth
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal, so the description carries the full burden. It details error handling (session not found, file not exist, permissions, size) and return format, going beyond basic adverticement.
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 well-structured with Args/Returns/Examples/Error sections, though slightly verbose. It remains focused and organized.
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 tool's complexity, annotations, and output schema, the description is complete with error handling and usage guidance. No gaps identified.
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 already describes each parameter well. The description adds value with examples and default file_mode explanation, justifying a score above 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 'Upload a local file to the remote server via SFTP', which is a specific verb and resource. It distinguishes itself from siblings like ssh_download_file.
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 explicit when-to-use examples (e.g., uploading config.json) and explicit don't-use scenarios (e.g., when remote file exists, suggesting alternatives like ssh_execute with rm).
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.
v1.0.2ssh_connectssh_disconnectssh_download_filessh_executessh_list_filesssh_statusssh_upload_fileEach tool has a distinct purpose: connect, disconnect, download, execute, list, status, upload. Descriptions clearly differentiate them with no overlap.
All tools begin with 'ssh_' followed by a verb or verb_noun pattern (e.g., ssh_connect, ssh_download_file). 'ssh_status' uses a noun but is still clear. Mostly consistent.
7 tools cover core SSH operations (connection, execution, file transfer, listing) without being excessive. Well-scoped for the domain.
Covers essential operations, but lacks explicit file manipulation (delete, rename, mkdir). These can be done via ssh_execute, so minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ifindv/ssh-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
