SSH MCP JumpServer enables AI agents to manage remote servers via SSH, with dynamic host discovery through JumpServer, security features, and connection pooling.
Core Operations:
List hosts (ssh_list_hosts): View all available SSH hosts from merged configuration (local project/user config + JumpServer).
Execute commands (ssh_exec): Run commands on any host (static or discovered via JumpServer) with optional timeout.
Get host config (ssh_get_config): Retrieve full merged SSH configuration for a specific host.
Test connectivity (ssh_test_connection): Verify SSH connection to a host.
Disconnect sessions (ssh_disconnect): Close one or all active SSH sessions.
Initialize config (ssh_init_config): Create or scaffold SSH config files at project or user level.
Smart Features:
JumpServer API dynamic discovery eliminates manual host configuration.
Automatic username fallback: tries root → ec2-user → game_server for JumpServer hosts.
Connection pooling reuses sessions across agent steps for performance.
Security: per-host allow/deny lists, dangerous command blocking, output truncation, secret redaction.
HMAC-SHA256 authentication to JumpServer.
Priority: command-line args > project config > user config > JumpServer.
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-jumpserver Connect to 10.0.0.5 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.
English | 中文
An MCP server that bridges AI agents (Claude Desktop, VS Code Copilot, etc.) to remote servers via SSH — with dynamic host discovery through JumpServer. No need to manually configure every host; if JumpServer knows it, you can connect to it.
JumpServer dynamic discovery: connect to any host JumpServer manages — no manual SSH config needed
Auto username fallback: tries root → ec2-user → game_server until one works
Standard SSH config support: still works with your existing OpenSSH config files for static hosts
Secure by default: dangerous command blocking, per-host allowlists/denylists, output caps, and secret redaction
Connection pooling: reuse SSH connections across agent steps for faster multi-turn sessions
Related MCP server: MCP SSH Server
npm install -g ssh-mcp-jumpserver
# or: npm install && npm run build && npm link{
"mcpServers": {
"ssh": {
"command": "ssh-mcp-jumpserver",
"args": [
"--ssh",
"name=prod,host=10.0.0.5,port=22,user=root,privateKey=~/.ssh/id_rsa"
],
"env": {
"JUMPSERVER_URL": "https://your-jumpserver.example.com",
"JUMPSERVER_KEY_ID": "your-access-key-id",
"JUMPSERVER_SECRET_ID": "your-access-secret-id"
}
}
}
}Static hosts passed with --ssh are searched first. If no static or config-file host matches, the server falls back to JumpServer discovery.
Ask your AI agent:
"Connect to 10.0.0.5 and run
uptime.""List all my SSH hosts."
"Test the connection to prod-db-01."
The server resolves unknown hosts through JumpServer automatically.
Feature | Description |
🔍 JumpServer dynamic discovery | Search assets by IP or hostname, fetch SSH keys via API |
🔄 Username fallback | Auto-tries |
📋 Static SSH config | Standard OpenSSH config ( |
🔒 Security policies | Per-host allowlist/denylist, output truncation, secret redaction |
🔌 Connection pool | Reuse SSH connections with idle cleanup |
🌐 HMAC-SHA256 auth | HTTP Signature signed requests to JumpServer API |
ssh-mcp-jumpserver [options]
--jumpserver-url <url> JumpServer base URL (enables dynamic host discovery)
--jumpserver-key-id <id> JumpServer Access Key ID
--jumpserver-secret-id <id> JumpServer Access Secret ID
--project-root <path> Project root (for project-level ssh.config)
--ssh <config> Static SSH host, repeatable:
name=prod,host=10.0.0.5,port=22,user=root,password=...
--timeout <ms> Default command timeout (default: 60000)
--max-output <chars> Max output characters (default: 10000)
--max-connections <n> Max concurrent SSH connections (default: 5)
--idle-timeout <ms> Connection idle timeout (default: 600000)Environment variable equivalents: JUMPSERVER_URL, JUMPSERVER_KEY_ID, JUMPSERVER_SECRET_ID.
Host lookup priority: --ssh args → project ssh.config → user config → JumpServer fallback.
Tool | Description |
| List all configured SSH hosts |
| Execute a command on a host (local config or JumpServer) |
| Show merged config for a host |
| Test SSH connectivity |
| Close SSH session(s) |
| Scaffold a new SSH config file |
User request: ssh_exec host="10.0.0.5"
→ Is "10.0.0.5" in local ssh.config?
├── Yes → connect directly
└── No → query JumpServer API
├── GET /api/v1/assets/assets/?ip=10.0.0.5
├── GET /api/v1/assets/system-users/?asset=<id>
├── GET /api/v1/assets/system-users/<id>/auth-info/
→ Build SSHHostConfig with discovered key
→ Try root → ec2-user → game_server
→ Execute commandSee CONTRIBUTING.md.
MIT — see LICENSE.
Disconnect SSH session(s). Specify a host to disconnect one, or omit to disconnect all.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | SSH host alias to disconnect (omit for all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'disconnect' without detailing behavior like graceful termination, error handling, or prerequisites (e.g., active session required).
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?
Two sentences, zero wasted words, front-loaded with verb and resource. Highly 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 disconnect tool with no output schema and no annotations, the description covers the core use case. Minor gaps like behavior on non-existent host or confirmation, but overall adequate.
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 coverage is 100% with description for 'host'. The tool description reinforces schema info but adds no extra meaning, 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 the tool disconnects SSH sessions, with specific behavior for one host vs all. This distinguishes it from sibling tools like ssh_exec or ssh_list_hosts.
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 explains when to specify a host (disconnect one) and when to omit (disconnect all). No explicit exclusions or alternatives, but guidance is clear.
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 a remote SSH host. The host must be defined in the SSH configuration or resolvable via JumpServer.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH host alias from the configuration, or an IP/hostname to resolve via JumpServer | |
| command | Yes | Command to execute on the remote host | |
| timeout_ms | No | Command timeout in milliseconds (default: 60000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the basic operation and host requirement, omitting critical details like return value (stdout/stderr), failure behavior, or that timeout_ms parameter exists. This is insufficient for an agent to predict side effects.
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?
Two sentences with no filler. The first sentence front-loads the primary action, and the second adds a critical constraint. Every word earns its place.
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 no output schema and simple parameters, the description should explain what the tool returns (e.g., command output) and any side effects. It does not. Also, sibling tools exist for connection testing, but no guidance on when to use exec vs test. The description is too minimal for confident selection.
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 descriptions cover 100% of parameters, so the baseline is 3. The tool description does not add any additional meaning beyond what the schema already provides for host, command, or timeout_ms.
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 ('Execute a command') and the target resource ('remote SSH host'). It distinguishes from siblings like ssh_test_connection (which tests connectivity) and ssh_get_config (reads config) by specifying execution of commands. The host constraint adds specificity.
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 when you need to run a command on a remote host, but it does not explicitly contrast with sibling tools like ssh_test_connection or ssh_disconnect. It mentions a prerequisite (host must be defined), but no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full SSH configuration for a specific host (merged from project + user level, or JumpServer)
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH host alias to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes merging behavior but does not disclose side effects, prerequisites, or output details, which is a gap.
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 one concise sentence, front-loaded with verb and resource, with no wasted words.
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 with no output schema or annotations, the description is adequate but does not explain the output format or full scope of 'full configuration'.
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 coverage is 100% with 'SSH host alias to look up'. The description reinforces 'for a specific host' but adds no significant new meaning beyond the 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 the tool retrieves the full SSH configuration for a specific host, with merging context. It distinguishes from sibling tools like ssh_exec and ssh_disconnect.
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 specifies when to use it (for a specific host) and provides context about merged configuration levels. It does not explicitly state when not to use it, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize an SSH configuration file (project-level or user-level)
| Name | Required | Description | Default |
|---|---|---|---|
| hosts | No | Host names to include in the template | |
| scope | Yes | Whether to create project-level or user-level config | |
| project_root | No | Project root directory (required for project scope) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits like whether the tool overwrites existing configs, side effects, or required permissions. It only says 'Initialize' with no further details.
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 sentence with no wasted words, efficiently stating the tool's 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?
Given the simplicity of the tool (init config), the description is adequate but lacks behavioral details. No output schema exists, so return value is not explained, but that may be acceptable for an init operation.
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?
All three parameters are described in the schema (100% coverage). The description does not add extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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 verb 'Initialize' and the resource 'SSH configuration file', and specifies the two scopes (project-level or user-level), making it distinct from siblings like ssh_get_config.
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 on when to use this tool versus alternatives such as ssh_get_config or ssh_list_hosts. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available SSH hosts from merged configuration (project + user level)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool reads from merged configuration, implying a read-only operation. However, it does not explicitly state safety, authorization requirements, or any side effects, which would improve transparency.
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 sentence, front-loads the core purpose, and contains no unnecessary words. Every part earns its place.
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 simplicity (no parameters, no output schema), the description is complete enough. It tells what the tool does and the data source. Minor addition of return type would be ideal but not critical.
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 zero parameters with 100% schema description coverage. According to guidelines, a baseline of 4 is appropriate. The description does not need to add parameter information since none exist.
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 verb 'List' and the resource 'all available SSH hosts', and adds context about the source being merged configuration from project and user levels. This effectively differentiates it from sibling tools like ssh_disconnect, ssh_exec, 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?
The description implicitly indicates when to use (to see available hosts) but does not explicitly state when not to use or name alternatives. It would benefit from a brief usage hint, such as 'Use before connecting to list accessible hosts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test SSH connectivity to a configured host (or a JumpServer-resolved host)
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH host alias to test |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the purpose without disclosing behavioral traits such as return value (e.g., boolean or error), side effects, authentication requirements, or what happens on failure.
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, front-loaded sentence that efficiently communicates the core function. It is appropriately concise, though some might argue it could include more context without losing brevity.
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 (one parameter, no output schema, no annotations), the description provides the minimum viable information. However, it omits details about the output or error behavior, which may leave the agent uncertain about what to expect after invoking the 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 input schema has 100% coverage with a description for the 'host' parameter. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
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 ('Test SSH connectivity') and the resource ('a configured host or a JumpServer-resolved host'). It is specific and distinct from sibling tools (ssh_disconnect, ssh_exec, etc.), which perform other operations.
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 for checking connectivity before other SSH operations, but it lacks explicit guidance on when to use or avoid this tool, or mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: disconnect, execute commands, get config, initialize config, list hosts, and test connectivity. No overlapping functionality.
All tools follow a consistent 'ssh_verb_noun' pattern using snake_case, making it easy to predict tool names and their actions.
6 tools cover the core SSH management operations without being excessive or insufficient, fitting the server's scope well.
Covers key operations (exec, disconnect, config, list hosts, test), but lacks an explicit 'ssh_connect' tool; however, exec and test effectively handle connection initiation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/helloNice/ssh-mcp-jumpserver'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
