Enables SSH connectivity and remote command execution on Raspberry Pi devices, allowing testing of connections and running commands with stdout, stderr, and exit code responses.
Enables SSH connectivity and remote command execution on Ubuntu servers, allowing testing of connections and running commands with stdout, stderr, and exit code responses.
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 Server test connection to my raspberry pi"
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) server that enables SSH connectivity and remote command execution. This server can run locally to access private networks or via Smithery for public servers.
ssh_test_connection: Tests connectivity to the configured host and returns hostname
ssh_run: Executes commands remotely and returns stdout, stderr, and exit code
Related MCP server: SSH MCP Server
Best for developers who want to modify the code or contribute to the project.
Clone and build:
git clone https://github.com/lgariv/ssh-mcp
cd ssh-mcp
npm install
npm run buildAdd to your MCP client config:
{
"mcpServers": {
"ssh-mcp": {
"command": "node",
"args": ["path/to/ssh-mcp/dist/index.js"],
"env": {
"SSH_HOST": "192.168.1.100",
"SSH_PORT": "22",
"SSH_USERNAME": "ubuntu",
"SSH_PASSWORD": "your-password"
}
}
}
}Best for accessing servers on your local network (LAN) or private IPs. Runs on your machine.
Add to your MCP client config:
{
"mcpServers": {
"ssh-mcp": {
"command": "npx",
"args": ["-y", "@lgariv/ssh-mcp@latest"],
"env": {
"SSH_HOST": "10.0.0.116",
"SSH_PORT": "22",
"SSH_USERNAME": "admin",
"SSH_PASSWORD": "your-password"
}
}
}
}Benefits:
No installation required
Always uses the latest version
Can access local network resources (192.168.x.x, 10.x.x.x, etc.)
Credentials stay on your machine
Best for accessing publicly accessible SSH servers. Runs on Smithery's infrastructure.
⚠️ Important: This method only works with publicly accessible servers. It cannot access private IPs or LAN resources.
Add to your MCP client config:
{
"mcpServers": {
"ssh-mcp": {
"type": "http",
"url": "https://server.smithery.ai/lgariv/ssh-mcp/mcp",
"config": {
"sshHost": "public.example.com",
"sshPort": 22,
"sshUsername": "ubuntu",
"sshPassword": "your-password"
}
}
}
}All methods require these environment variables or config parameters:
Parameter | Description | Default |
| Target SSH server IP/hostname | Required |
| SSH port number | 22 |
| SSH username | Required |
| SSH password | Required |
Use Case | Recommended Method |
Local home lab servers | Method 2 (NPM) |
Raspberry Pi on LAN | Method 2 (NPM) |
Local VMs or containers | Method 2 (NPM) |
Development and testing | Method 1 (Source) |
Cloud VPS with public IP | Method 3 (Smithery) |
Public web servers | Method 3 (Smithery) |
Methods 1 & 2: Credentials are stored locally in your MCP configuration
Method 3: Credentials are sent to Smithery's servers (use only with public servers)
Always use strong passwords and consider SSH keys for production use
Ensure your MCP configuration file has appropriate permissions
# Install dependencies
npm install
# Run in development mode
npm run dev
# Build for production
npm run build
# Run built version
npm startISC
lgariv
Runs a non-interactive command remotely over SSH and returns stdout, stderr, and exit code
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command to run remotely |
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 states the tool returns 'stdout, stderr, and exit code', which is useful, but lacks critical details like authentication requirements (e.g., SSH key or password), error handling (e.g., connection failures), rate limits, or whether it modifies remote systems. For a tool that executes remote commands, this is a significant gap in safety and operational 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?
The description is a single, efficient sentence that front-loads the core functionality ('runs a non-interactive command remotely over SSH') and includes the return values. There is zero wasted text, and every word earns its place by conveying essential information without 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 the complexity of SSH command execution (involving remote systems, authentication, and potential side effects), the description is incomplete. With no annotations to cover safety or behavioral traits, and no output schema to detail return values beyond a brief mention, the description fails to provide enough context for safe and effective use. It should address authentication, error scenarios, or destructive potential.
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 description coverage is 100%, with the single parameter 'command' well-documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples, constraints, or usage tips for the command parameter). Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 specific action ('runs a non-interactive command remotely over SSH') and the resource ('command'), distinguishing it from the sibling tool 'ssh_test_connection' which likely tests connectivity rather than executing commands. The verb+resource combination is precise and unambiguous.
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 no guidance on when to use this tool versus the sibling 'ssh_test_connection' or any alternatives. It mentions 'non-interactive' but doesn't explain when interactive commands might be needed or what other tools could handle them. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attempts to connect to the configured SSH host and returns the remote hostname
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the connection attempt and return value, but doesn't disclose important behavioral traits like: what happens on connection failure (error message format), timeout behavior, authentication requirements, whether it modifies any state, or if it has rate limits. For a connectivity tool with zero annotation coverage, this is insufficient.
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 a single, efficient sentence that communicates the core functionality and return value. It's front-loaded with the main action and has zero wasted words. Every part of the sentence earns its place by conveying essential information.
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 (0 parameters, no output schema), the description is reasonably complete for basic understanding. However, without annotations and with no output schema, it should ideally describe what happens on failure and the format of the return value. The description mentions the return but doesn't specify if it's a string, object, or what happens if connection fails.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing non-existent parameters. It correctly focuses on what the tool does rather than parameter documentation.
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 ('attempts to connect') and resource ('configured SSH host'), and specifies the return value ('returns the remote hostname'). It distinguishes from the sibling 'ssh_run' by focusing on connection testing rather than command execution. However, it doesn't explicitly mention that this is for validation/diagnostic purposes, which would make it a perfect 5.
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 no guidance on when to use this tool versus the sibling 'ssh_run'. It doesn't mention prerequisites like needing SSH configuration or suggest this should be used before running commands. There's no explicit when/when-not guidance or alternative tool recommendations.
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.0ssh_run2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsessh_test_connection1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"ssh_runssh_test_connectionThe two tools have completely distinct purposes: ssh_run executes commands and returns results, while ssh_test_connection only tests connectivity and returns hostname. There is no overlap or ambiguity between them.
Both tools follow a consistent 'ssh_' prefix pattern with clear verb_noun naming (ssh_run and ssh_test_connection). The naming is predictable and follows the same convention throughout.
With only 2 tools, this server feels severely under-scoped for SSH operations. While the tools cover basic connectivity and command execution, there are many obvious missing SSH functionalities like file transfer, session management, or interactive operations.
For an SSH server, the surface is significantly incomplete. There's no file transfer (scp/sftp), no interactive shell capability, no key management, no port forwarding, and no session persistence. Agents will hit dead ends trying to perform common SSH tasks beyond basic command execution.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Run commands and read/write files on your servers over Termalin's keyless tunnels (hosted MCP).
Secure tunneling, reverse proxy and remote access for local applications.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lgariv/ssh-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
