Remote SSH MCP

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct action in the SSH session lifecycle: open creates, run executes, interrupt signals, peek observes, list enumerates, close destroys. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow the same ssh_verb pattern using clear, imperative verbs (open, run, interrupt, peek, list, close). The naming is perfectly consistent.
Tool Count5/5
Six tools is an ideal scope for managing remote SSH sessions. Each tool is necessary and none are redundant, covering the full lifecycle without bloat.
Completeness5/5
The tool set covers the complete lifecycle of a persistent remote shell: open, run, monitor, interrupt, list, and close. Given the non-interactive design constraint, there are no evident gaps for the intended domain.
Average 4.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the session is kept only when recovery is confirmed and that it waits for recovery, going beyond the destructiveHint annotation. Reveals return behavior for idle state.
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?
Two sentences, direct, no redundant words, front-loads the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main behavior and idle return, but omits how the id parameter relates to the session and lacks error cases beyond idle. Given simple schema and no output schema, it's mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description never explains the required 'id' parameter. The agent cannot learn from the description what id identifies or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sends Ctrl-C to the current foreground process group, distinguishing it from open/run/peek/list/close siblings. Specific verb 'send' and resource 'foreground process group'.
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?
Describes the recovery wait and the 'nothing_to_interrupt' when idle, which guides when it's applicable. Does not explicitly name alternatives but context implies interrupt vs other session operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: sessions are clean and get a new id, credentials only come from local OpenSSH config/agent, and passwords/private keys are never accepted as arguments nor read from disk. This safety-related transparency is valuable.
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?
Three focused sentences; every sentence provides useful information without excess. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key constraints (persistent shell, allowed hosts, credential handling, clean session), but does not describe the return value or lifecycle (how to use/close the session). Given no output schema, a mention of what the tool returns or how the session id is used would be helpful.
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?
Describes the 'host' parameter semantically as an allowed ssh_config Host alias from ssh_hosts, but does not explain the 'name' parameter. Schema coverage is 0%, so the description partially compensates but leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Open') on a specific resource ('a new persistent remote bash shell'), and distinguishes itself from siblings by specifying usage of an allowed ssh_config Host alias from ssh_hosts and clean sessions with new ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that this is for persistent sessions using allowed hosts, but does not explicitly name alternatives like ssh_run or ssh_peek or state when to use them. The 'from ssh_hosts' constraint gives some usage guidance, but it lacks explicit when/when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable behavioral details: it cleans a private temporary directory and invalidates the id. This surpasses what annotations alone convey, while remaining consistent with them. There is no contradiction.
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 brief, two sentences, with the primary action stated upfront. Every sentence adds value: the first defines the behavior, the second gives a practical use case. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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) and the annotations covering safety profile, the description covers the essential aspects: what is closed, what is cleaned, and when to reopen. The sibling context is clear from the name itself. Nothing critical is missing for an agent to invoke it correctly.
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 schema has one required parameter 'id' with a pattern, but no description. The description indirectly clarifies its meaning by stating it "invalidate[s] the id," confirming that id refers to the session identifier. While it could explicitly say 'the id returned by ssh_open', the context and pattern make the parameter's purpose clear enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: "Close the remote shell and SSH connection." It also adds specific cleanup actions (clean private temporary directory, invalidate the id), which distinguishes it from the sibling tools like ssh_open and ssh_interrupt. The verb 'close' is specific and unambiguous.
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 a usage pattern: "Close a dirty session and call ssh_open for a clean environment." This implies when the tool is appropriate (for dirty sessions) and suggests a follow-up action. However, it does not explicitly contrast with alternatives like ssh_interrupt or state when not to use it, missing the full 'when/when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive hints, so the description adds value by specifying the exact fields returned and the 'live session' scope. The mention of 'idle-reap countdown' provides extra lifecycle context beyond what annotations convey, though it does not detail the output format or pagination.
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 two sentences with zero filler. It front-loads the core action, then packs in specific return fields and a critical usage reminder. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description fully covers behavior, return field details, and usage instructions. The agent knows exactly what to expect from the call and how to apply it, making the tool self-contained.
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 no parameters, and the schema is empty, so the baseline is 4 per the rubric. The description accurately reflects the parameterless nature and adds no unnecessary parameter details. Nothing is needed beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all live SSH sessions with a specific set of fields (host, cwd, state, etc.). This distinguishes it from sibling tools that open, run, interrupt, peek, or close sessions. The verb 'list' unambiguously defines the action.
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 explicitly directs users to use this tool to recover valid session ids and warns against inventing ids, which is crucial for safely using other ssh commands. It lacks an explicit 'when not to use' or alternative comparison, but the context of the sibling tools makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral detail: returns only safe connection metadata, never exposes private keys/IdentityFile paths/agent sockets/ProxyCommand, and re-parses config without restarting. This is consistent with the annotations.
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 compact and front-loaded with the main purpose, then adds safety guarantees, reload guidance, and a pointer to ssh_open. Every sentence earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description adequately explains return values (alias, hostname, user, port, proxy_jump) and exclusions. It also covers parameter behavior. For a simple list tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It fully explains the reload parameter: passing reload=true after editing ~/.ssh/config re-parses without restarting the MCP server. This adds clear meaning beyond the boolean type and default.
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 lists allowed OpenSSH Host aliases from local ssh_config and an explicit allowlist, with a specific resource and scope. However, with a sibling named ssh_list that could also be a listing tool, there is no explicit differentiation from that sibling, preventing a 5.
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 gives clear usage context: use this to discover aliases for ssh_open, and pass reload=true after editing ~/.ssh/config. It does not explicitly state when not to use it or name alternatives among the sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=true), the description adds rich behavioral detail: wait_sec behavior with status=running, no automatic timeout, timeout_sec sending Ctrl-C, one foreground command per id, and persistence of cwd/environment changes.
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 front-loaded with the core operation and then provides precise behavioral and usage clauses. Every sentence adds value, and the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The lifecycle, timeout, concurrency, and restrictions are thoroughly covered. However, with no output schema, the description does not specify the return payload for completed commands—only mentioning status=running for still-active commands. This is a minor but non-negligible gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero property descriptions, but the description fully compensates: id identifies the persistent shell, command is non-interactive, wait_sec is the call wait limit with a default, and timeout_sec triggers Ctrl-C at the deadline. All four parameters are semantically grounded.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a non-interactive command in the same persistent shell identified by id, with persistent cwd and environment changes. This distinguishes it from sibling tools like ssh_open (new session) and ssh_peek/ssh_interrupt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: poll with ssh_peek(wait_sec=...), call ssh_interrupt to stop, open another session for concurrency, and never retry a running command. It also explicitly forbids interactive TUI/input flows such as vim or top.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds key behavioral details: wait_sec long-polls but never stops the remote command, output is limited independently for stdout/stderr, lines are capped to protect model context, and idle returns cwd and last exit code. These traits are not in the annotations and significantly enhance transparency.
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 well-structured and each sentence adds unique value: purpose, wait_sec semantics, output behavior, usage context, and idle behavior. There is no fluff or redundancy, and the length is justified given the parameter complexity and zero schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description thoroughly explains return values: newest lines in chronological order for stdout/stderr, and when idle, cwd, last exit code, and latest lines. It also covers all operational states (running vs idle) and parameter effects, making the tool fully comprehensible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. It explains wait_sec's long-polling behavior and that it never stops the command, lines defaults to 50 with a cap, and id is implicitly tied to ssh_run's returned handle. This gives meaning to all three parameters beyond their raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool observes the current foreground command and its latest output without starting another command. It distinguishes itself from siblings like ssh_run (start) and ssh_interrupt (interrupt) by focusing on passive observation. The verb 'observe' plus specific resource (SSH command output) makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after ssh_run returns status=running', giving a clear when-to-use directive. It also advises preferring a positive wait_sec over busy-looping, which is a practical usage guideline. The idle-state description further clarifies expected behavior in different conditions.
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:

[![remote-ssh-mcp MCP server](https://glama.ai/mcp/servers/the-nine-nation/remote-ssh-mcp/badges/card.svg)](https://glama.ai/mcp/servers/the-nine-nation/remote-ssh-mcp)

Score Badge

Copy to your README.md:

[![remote-ssh-mcp MCP server](https://glama.ai/mcp/servers/the-nine-nation/remote-ssh-mcp/badges/score.svg)](https://glama.ai/mcp/servers/the-nine-nation/remote-ssh-mcp)

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/the-nine-nation/remote-ssh-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server