The NHN Server MCP is a Model Context Protocol server that provides secure SSH gateway access to remote servers with Kerberos authentication and command execution capabilities.
Core Capabilities:
Execute Remote Commands (exec) - Run commands on specified servers through an SSH gateway with required host, user, and command parameters
View Server Configuration (get_config) - Query current settings including allowed hosts, whitelisted commands, and server information like log paths
Reload Configuration (reload_config) - Dynamically reload the configuration file without restarting
Check Connection Status (connection_status) - Monitor the current SSH gateway connection state
Disconnect from Gateway (disconnect_server) - Manually terminate the SSH gateway connection
Security Features:
Kerberos (kinit) authentication support
Host allowlist to restrict server access
Command whitelisting
macOS native confirmation dialogs with "always allow" option for trusted commands (session-scoped)
Automatic session cleanup after 5 minutes of inactivity
Prevents sensitive config file commits
Use Cases:
Access servers behind SSH gateways from AI assistants
Retrieve and analyze server logs
Execute maintenance commands with approval workflows
Enable AI to understand server topology and log locations
Configure for project-specific or global use across Claude CLI, Desktop, and other MCP clients
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., "@NHN Server MCP show me the last 50 lines of the app log on server1"
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 CLI tool for executing commands and transferring files to remote servers via an SSH Gateway.
Remote server command execution via SSH Gateway (real-time streaming output)
Parallel execution on multiple hosts (single Gateway authentication + internal fan-out)
SCP file upload/download via Gateway (binary integrity guaranteed)
Kerberos authentication (kinit) support
Prevents process hangs with remote command timeouts
Access restriction via host allowlist
Related MCP server: Windows CLI MCP Server
npm install
npm run build
npm link # gw-ssh 명령어 글로벌 등록{
"gatewayConnection": "user@gateway.example.com:22",
"gatewayPassword": "your-password",
"kinitPassword": "your-kerberos-password",
"allowedHosts": ["server1", "server2"],
"commandTimeoutSec": 300,
"serverInfo": {
"user": "default-ssh-user",
"logPaths": {
"app": "/var/log/app"
}
}
}# 방법 1: 환경변수 (~/.zshrc 등에 추가)
export CONFIG_FILE=/path/to/config.json
# 방법 2: --config 옵션
gw-ssh -c /path/to/config.json <command>Key | Description | Default |
| Gateway SSH connection (user@host:port) | Required |
| Gateway SSH password | Required |
| Kerberos authentication password (skips kinit if not set) | - |
| List of allowed hosts | [] (allow all) |
| Remote command timeout (seconds). Wrapped with GNU timeout | 300 |
| Server meta information (user, logPaths, etc.) | {} |
Variable | Description |
| Path to config.json file |
| Enable debug logs ( |
gw-ssh exec <host> <command> [-u user] [-j jobs] [--buffered]# 단일 호스트
gw-ssh exec server1 "hostname"
gw-ssh exec server1 "uptime" -u appuser
# 로그 조회
gw-ssh exec server1 "tail -100 /var/log/app/app.log"
gw-ssh exec server1 "grep ERROR /var/log/app/app.log | tail -20"If -u is omitted, the serverInfo.user value is used.
If you pass a comma-separated CSV to <host>, it automatically operates in parallel mode. Gateway authentication/Kerberos ticket is performed only once, and fan-out occurs in the gateway→target segment.
# 3개 호스트에서 동시에 실행 (기본 동시성 5)
gw-ssh exec server1,server2,server3 "hostname && uptime"
# [server1] server1
# [server1] 15:02:31 up 42 days, ...
# [server2] server2
# [server2] 15:02:31 up 12 days, ...
# [server3] server3
# [server3] 15:02:31 up 7 days, ...
# ✓ 3/3 성공
# 동시성 제한 변경 (gateway 부하 고려해 3~10 권장)
gw-ssh exec h1,h2,h3,h4,h5,h6,h7,h8 "uptime" -j 10
# 호스트별로 출력을 모아 순서대로 표시 (스트리밍 대신 버퍼드 모드)
gw-ssh exec h1,h2 "cat /etc/hostname" --bufferedIf some hosts fail, a failure summary is printed to stderr with exit code 1.
gw-ssh upload <host> <remotePath> [options] [-u user] [-j jobs]# 텍스트 내용 직접 업로드
gw-ssh upload server1 /tmp/hello.txt --content "hello world"
# 로컬 파일 업로드 (바이너리 포함 - gzip, zip, 실행파일 등)
gw-ssh upload server1 /tmp/app.tar.gz --file ./app.tar.gz
# 여러 호스트에 같은 파일 동시 배포 (CSV 지정 시 병렬 모드)
gw-ssh upload server1,server2,server3 /tmp/app.tar.gz --file ./app.tar.gzWhen uploading to multiple hosts, the local→gateway transfer occurs once, and gateway→each target is fanned out in parallel. The larger the file or the more hosts, the greater the local bandwidth savings.
gw-ssh download <host> <remotePath> [options] [-u user] [-j jobs]# 표준 출력으로 내용 확인
gw-ssh download server1 /etc/hosts
# 로컬 파일로 저장
gw-ssh download server1 /etc/hosts -o ./downloaded-hosts.txt
# 바이너리 파일도 무결성 유지 (gzip, zip, 실행파일 등)
gw-ssh download server1 /var/app/release.tar.gz -o ~/Downloads/release.tar.gz
# 여러 호스트에서 동시에 다운로드 — -o 에 디렉토리 지정, 파일명 앞에 호스트 접두
gw-ssh download server1,server2 /var/log/app.log -o ~/Downloads/
# → ~/Downloads/server1-app.log
# → ~/Downloads/server2-app.log-o must be a file path for a single host, or an already existing directory path for multiple hosts.
In multi-host downloads, if only some hosts fail, the files from the successful hosts remain in the -o directory. Manual deletion is required if a full rollback is needed.
gw-ssh configgw-ssh statusDo not commit config.json to git as it contains sensitive information (passwords)
Restrict accessible servers with allowedHosts
Command safety ensured with Base64 encoding + shell injection prevention patterns
Automatic SSH session cleanup even when exceptions occur
MIT
현재 SSH 연결 상태를 확인합니다.
| 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 of behavioral disclosure. It states the tool checks connection status, implying a read-only operation, but doesn't disclose any behavioral traits such as whether it requires authentication, has rate limits, returns specific data formats, or if it's safe to use frequently. This is a significant gap for a tool with no annotation coverage.
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 in Korean that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool, earning a high score for 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 has no annotations, no output schema, and 0 parameters, the description is minimal. While it states the purpose, it lacks completeness by not providing behavioral context (e.g., what the check entails, return format, or error handling). For a status-checking tool, more details would help the agent understand how to interpret results.
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, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied as per the rules for tools with zero parameters.
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 purpose as '현재 SSH 연결 상태를 확인합니다' (checks the current SSH connection status), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'disconnect_server' or 'get_config', which might also involve connection status in different contexts, so it doesn't reach the highest score.
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 alternatives. It doesn't mention prerequisites, when-not-to-use scenarios, or compare to siblings like 'disconnect_server' (which might affect connection) or 'get_config' (which might include status info). This leaves the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gateway 연결을 종료합니다.
| 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 for behavioral disclosure. While '종료합니다' (disconnect/terminate) implies a destructive action, the description doesn't specify whether this is reversible, what permissions are required, whether it affects other operations, or what happens after disconnection. For a potentially disruptive 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 directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information without unnecessary elaboration.
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 potentially destructive operation (disconnecting a gateway connection) with no annotations and no output schema, the description is incomplete. It doesn't explain what 'Gateway 연결' refers to specifically, what the consequences of disconnection are, whether there are dependencies, or what verification/confirmation might be needed. Given the complexity and risk profile, more context would be appropriate.
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 schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, which is correct. Baseline for 0 parameters is 4, as the description doesn't need to compensate for any parameter documentation gaps.
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/terminate) and the target resource ('Gateway 연결' - Gateway connection), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'connection_status' or 'exec', which would require more specific language about what makes this tool unique.
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 alternatives like 'connection_status' (which might check connection state) or 'exec' (which might execute commands on the server). There's no mention of prerequisites, consequences, or appropriate contexts for disconnecting versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
서버에서 명령어를 실행합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | 명령어를 실행할 서버 호스트명 | |
| user | Yes | SSH 접속 사용자명 (예: irteam, irteamsu) | |
| command | Yes | 실행할 명령어 (화이트리스트 명령어만 허용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states execution happens but doesn't disclose critical behaviors: security constraints (whitelist mentioned in schema but not description), authentication needs (SSH implied by user parameter), potential side effects, error handling, or output format. For a command execution tool with zero annotation coverage, this leaves significant gaps.
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?
Extremely concise single sentence with zero waste. It's front-loaded and directly states the core purpose without unnecessary elaboration. 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 this is a potentially dangerous command execution tool with no annotations and no output schema, the description is incomplete. It doesn't cover security implications, execution environment, error cases, or what the tool returns. The schema covers parameters well, but behavioral context is severely lacking.
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 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond what's in the schema (e.g., doesn't explain command whitelist details or host format). Baseline 3 is appropriate when the schema does the heavy lifting.
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 '서버에서 명령어를 실행합니다' (executes commands on a server), which provides a basic verb+resource. However, it's vague about what type of commands or execution mechanism (SSH implied by parameters but not stated). It doesn't distinguish from siblings like 'connection_status' or 'disconnect_server', which are clearly different 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?
No guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., server must be reachable), when-not-to-use scenarios, or how it relates to sibling tools like 'disconnect_server' or 'get_config'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
서버 설정 정보를 조회합니다. 허용된 호스트, 명령어, 서버 정보 등을 확인할 수 있습니다.
| 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 full burden for behavioral disclosure. It states this is a read operation ('조회합니다' - retrieves/checks), implying it's non-destructive, but doesn't specify authentication requirements, rate limits, error conditions, or what happens if the server is unavailable. For a configuration tool with zero annotation coverage, this leaves significant behavioral gaps.
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 concise with two sentences. The first sentence states the core purpose, and the second elaborates on what specific information can be checked. There's no wasted language, though it could be slightly more structured by explicitly separating scope 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?
Given the tool's complexity (simple read operation with no parameters) and lack of annotations/output schema, the description is minimally adequate. It explains what data is retrieved but doesn't cover behavioral aspects like permissions or error handling. For a configuration tool, more context about security or operational constraints would be 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?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, but it does clarify what information is retrieved (allowed hosts, commands, server info), which adds context about the return data. This exceeds the baseline expectation for a zero-parameter 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 clearly states the tool's purpose: '서버 설정 정보를 조회합니다' (retrieves server configuration information). It specifies the resource (server configuration) and verb (retrieves/checks), and mentions specific data types included (allowed hosts, commands, server information). However, it doesn't explicitly differentiate from sibling tools like 'reload_config' or 'connection_status'.
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 alternatives. It doesn't mention prerequisites, appropriate contexts, or comparisons with sibling tools like 'reload_config' (which might modify configuration) or 'connection_status' (which might check connectivity rather than settings). The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
서버 설정을 다시 로드합니다. SERVER_INFO_FILE 등이 변경되었을 때 사용합니다.
| 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 the full burden of behavioral disclosure. It states the action ('reload server configuration') and context of use, but doesn't describe what 'reload' entails behaviorally - whether it requires specific permissions, if it interrupts service, what happens on failure, or what the response looks like. The description adds basic context but lacks detailed behavioral traits.
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 perfectly concise with two sentences that each earn their place: the first states the core action, the second provides usage context. It's front-loaded with the primary purpose and wastes no words. The Korean language doesn't affect conciseness scoring.
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 has no parameters (simple interface) and no output schema, the description provides adequate but minimal context. It explains what the tool does and when to use it, but doesn't address what happens during execution, potential side effects, or what constitutes success/failure. For a configuration reload operation with no annotations, more behavioral context would be 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?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, and the baseline for 0 parameters is 4. No additional parameter semantics are needed or provided.
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 ('reload') and resource ('server configuration'), making the purpose specific and understandable. It distinguishes from siblings by focusing on configuration reloading rather than status checking, connection management, or command execution. However, it doesn't explicitly differentiate from 'get_config' which might retrieve configuration without reloading.
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 clear context for when to use the tool ('when SERVER_INFO_FILE etc. have been changed'), giving practical guidance. It doesn't explicitly state when NOT to use it or name alternatives among siblings, but the context implies it's for applying configuration changes rather than general operations.
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 clearly distinct purpose with no overlap: connection_status checks SSH status, disconnect_server terminates connections, exec runs commands, get_config retrieves settings, and reload_config reloads configurations. The descriptions reinforce these distinct roles, making misselection unlikely.
All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., connection_status, disconnect_server, exec, get_config, reload_config). This uniformity enhances readability and predictability across the set.
With 5 tools, this server is well-scoped for managing SSH connections and server configurations. Each tool earns its place by covering essential operations like status checks, command execution, and configuration handling without being overly sparse or bloated.
The tool set provides strong coverage for SSH and server management, including status, disconnection, command execution, and configuration operations. A minor gap exists in lacking a tool for initiating or establishing new SSH connections, but agents can work around this using exec or other methods.
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.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Unified gateway exposing 150+ tools across all NexGenData MCP servers via one endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dhks77/gw-ssh'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
