NHN Server MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.2/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gw-ssh MCP server](https://glama.ai/mcp/servers/dhks77/gw-ssh/badges/card.svg)](https://glama.ai/mcp/servers/dhks77/gw-ssh)

Score Badge

Copy to your README.md:

[![gw-ssh MCP server](https://glama.ai/mcp/servers/dhks77/gw-ssh/badges/score.svg)](https://glama.ai/mcp/servers/dhks77/gw-ssh)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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