ssh-mcp-server

by yuyi-clip

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes (execute, upload, service control, tunnel management), but ssh_check and ssh_system_status both report host health, and ssh_job_status versus ssh_job_list overlap in querying jobs. Descriptions help disambiguate, but the boundaries aren't perfectly sharp.
Naming Consistency4/5
All names use snake_case with a consistent ssh_ prefix and mostly a verb-first pattern (list, execute, start, cancel). However, ssh_service_control and ssh_file_progress deviate from the verb-noun structure, creating minor inconsistency.
Tool Count4/5
19 tools is on the higher end but justified by the broad scope covering execution, file transfer, job lifecycle, services, monitoring, and tunnels. The count feels slightly heavy but each tool serves a distinct area without redundancy.
Completeness4/5
The toolset provides strong lifecycle coverage for jobs, services, files, and tunnels, plus system and GPU monitoring. Minor gaps like remote directory listing or file deletion are absent but workaroundable, so core workflows are well-supported.
Average 3.4/5 across 19 of 19 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
The description adds no behavioral context beyond what the annotations already declare. Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already convey the safe, read-only nature. The description merely restates this with '读取', without disclosing additional traits like output format, remote requirements, or potential errors.
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 a single short sentence with no fluff, front-loaded with the action. However, it is too terse to be considered a model of clarity; it omits essential parameter and usage details. Still, it is concise and well-structured for what little it conveys.
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?
The tool has a moderate complexity with two required parameters and an output schema, but the description lacks crucial context: parameter semantics, usage scenarios, and any relation to the SSH/remote environment. The annotations and output schema partially compensate, but the description alone is insufficient for reliable invocation.
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 description coverage is 0% and the description fails to explain the 'alias' and 'service' parameters. With no parameter documentation in either schema or description, the agent has no way to understand what values to provide for these required fields.
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 states a specific verb ('读取' - read) and resource ('systemd 服务状态' - systemd service status), clearly indicating a query operation. It partially distinguishes from siblings like ssh_service_control (which implies control) and ssh_system_status (broader system status), though it doesn't explicitly differentiate or mention the alias/service scope.
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. There is no mention of prerequisites, typical scenarios, or contrasts with sibling tools like ssh_system_status or ssh_check. Only a bare statement of what it does, leaving the agent without context for selection.
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?
Annotations already declare readOnlyHint and non-destructive behavior. The description adds minimal context by mentioning 'status summary,' but it doesn't disclose additional behavioral aspects such as authentication requirements or result ordering. With annotations covering safety, a 3 is appropriate.
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 a single, concise sentence that is front-loaded with the action. While under-specified, it avoids unnecessary words and is appropriately brief for a simple listing tool.
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?
Despite having rich annotations and an output schema, the description fails to clarify parameter semantics and does not mention any optional behaviors (e.g., filtering). The tool is relatively simple, but the missing param information makes it incomplete for reliable use.
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?
The schema description coverage is 0%, and the description provides no explanation of the 'alias' or 'limit' parameters. Agents are left to guess that 'alias' is a server identifier and 'limit' caps the number of returned tasks. This is a significant gap for effective tool invocation.
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 remote tasks and their status summaries. The verb 'list' and resource 'remote task directory' distinguish it from related commands like ssh_execute or ssh_cancel_job, though it doesn't explicitly differentiate from ssh_job_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?
No guidance on when to use this tool vs. alternatives like ssh_job_status for a specific job. The usage is implied by the name but not explicitly stated, and there are no exclusions or prerequisites mentioned.
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?
The annotations already convey destructiveHint=true and readOnlyHint=false, so the agent knows it is a mutating operation. The description adds that the task is '可持续运行' (sustainable/long-running), but does not disclose other behavioral traits such as process persistence, output redirection, or cancellation behavior, which are relevant for such a tool.
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 a single concise sentence that front-loads the core action and use cases. It is well-structured and efficient, though it could be expanded to include parameter guidance without harming 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 three parameters, a destructive hint, and no schema descriptions, the description is insufficient. It lacks essential information about parameter meanings, job lifecycle, and relationship to monitoring tools. The presence of an output schema lessens the need to describe return values, but operational context remains severely under-specified.
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?
The input schema has 0% description coverage, and the description provides no explanation for any parameter (alias, label, command). The agent must infer their meaning solely from names, which is inadequate for correct invocation.
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 starts a remote background job (远程后台任务) and specifies common use cases (模型下载和推理). It distinguishes itself from siblings like ssh_job_status by the verb 'start' and the emphasis on long-running tasks, though it could be more explicit about the background aspect.
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?
It gives some usage context by stating it is suitable for model download and inference, implying long-running tasks. However, it does not explicitly compare with alternatives like ssh_execute for short-lived commands or mention when not to use this tool, leaving the relative decision to the agent.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, covering the mutation/destructive nature. The description adds little beyond restating actions; it does not disclose potential side effects like service downtime or privilege requirements, but does not contradict 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 a single sentence that directly states the core action set with no filler. It is efficient and front-loaded, earning high marks 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?
Despite an output schema existing, the description is minimal. It does not explain what `alias` refers to (likely an SSH server alias), that this is a remote operation, or any operational context such as permissions or side effects. This leaves significant gaps for a mutating control tool.
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 description coverage is 0%, and the description provides no additional meaning for parameters `alias`, `service`, or `action`. The action enum is repeated in the description, but alias and service remain undefined, so the description fails to compensate for the low coverage.
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: '启动、停止、重启或重载 systemd 服务' (start, stop, restart, or reload systemd services), using a specific verb set and resource. It distinguishes from siblings like ssh_service_status by focusing on control actions, though it doesn't explicitly name alternatives.
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?
The description implies usage whenever service control is needed, but provides no explicit guidance on when to use this tool versus alternatives like ssh_service_status or ssh_execute. There is no mention of exclusions or prerequisites, leaving the agent to infer context.
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?
Annotations already indicate destructiveHint=true, and the description adds the overwrite warning, which reinforces but does not add much beyond annotations. It does not mention authentication requirements, progress reporting, or failure behavior. The description adds some context about overwrite, but with annotations covering the destructive nature, a score of 3 is appropriate.
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 a single concise sentence that communicates the core action and a key risk. It is appropriately sized, but the lack of parameter information makes it slightly under-informative, though efficiency-wise it is fine.
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's complexity (5 parameters, destructive action, no schema descriptions), the description is too sparse. It covers the upload action and overwrite warning but omits parameter semantics, usage examples, and behavioral details like how overwrite is controlled by 'preserve'. The output schema exists, so return values are not needed, but the description still lacks critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The description mentions overwrite but not what 'preserve', 'recursive', 'alias', or path parameters do. With zero coverage in the schema, the description must compensate but fails to do so, resulting in a score of 2.
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 states '通过 SFTP 上传文件' (upload files via SFTP) with a specific verb and resource, clearly indicating the tool uploads files. It does not explicitly distinguish from sibling ssh_download or ssh_start_job, but the upload action is inherently distinct from other SSH tools, earning a 4 rather than 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool versus alternatives, but it does mention the overwrite risk ('目标已存在时可能被覆盖'), which provides context for cautious usage. No explicit exclusions or alternative tool names are given, so it only partially addresses usage guidelines.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the behavioral trait that multiple calls are required to compute a rate, which is useful beyond the annotations. It does not describe return values or side effects, but given the strong annotation coverage, this is adequate.
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 extremely concise: two short sentences. It front-loads the verb and resource, and every word adds value. There is no redundancy or unnecessary detail, making it highly efficient for an agent to parse.
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 3 parameters and 0% schema description coverage, the description is too sparse. It does not explain the role of expected_bytes or the return value semantics (partially mitigated by the output schema). The description lacks enough context for an agent to confidently invoke the tool without ambiguity about the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter meaning. It does not explain alias, remote_path, or expected_bytes. The overall purpose hints that remote_path is a file path, but no parameter-specific guidance is given, leaving the agent to guess how expected_bytes should be used.
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 states that the tool samples remote file size and that at least two calls are needed to calculate growth rate, which clearly identifies the verb (sample) and resource (remote file). The title additionally clarifies that this is for checking download speed, but the description itself does not explicitly distinguish it from sibling tools like ssh_download, so it lacks some differentiation.
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?
The description provides important usage guidance: 'call at least twice to calculate growth rate', but it does not explicitly state when to use this tool over alternatives (e.g., ssh_download) or mention any exclusions. The context of measuring speed is implied rather than explicitly contrasted with other ssh tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds minimal extra context, essentially restating the scope (specified systemd service). It does not mention potential output size, filtering behavior, or connection details, but with annotations covering the read-only nature, a baseline 3 is appropriate.
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 a single concise sentence, front-loaded with the core purpose. It is not verbose, but it is too thin to convey necessary detail; still, for what it does say, it is efficient.
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 log-reading tool, the description lacks important context: it does not mention that an alias is required to specify the remote server, nor the meaning of the lines/since parameters for filtering output. While an output schema exists, the description does not indicate whether output is raw text or structured, and no usage context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only hints at 'service' (specified systemd service) and ignores 'alias', 'lines', and 'since'. It fails to explain the meaning or usage of these parameters, placing the entire burden on the schema names, which are insufficient for correct invocation.
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 '读取指定 systemd 服务的 journal 日志' clearly specifies the action (read) and the resource (journal logs of a specified systemd service). It distinguishes this tool from siblings like ssh_execute and ssh_service_status by focusing on reading logs, which is a distinct operation.
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 is provided for when to use this tool versus alternatives. The description does not mention scenarios, prerequisites (e.g., needing alias to SSH), or contrast with other log-related commands. It only states what it does without contextual direction.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds no extra behavioral context beyond the return content, which is acceptable given the minimal bar set by 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 a single concise sentence that directly states the tool's purpose with no unnecessary words. It is well-structured and easy to parse.
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?
The tool is simple with one parameter and has output schema plus annotations. However, the missing parameter semantics and lack of usage guidance are notable gaps that prevent full completeness for an agent.
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?
The schema has 0% description coverage for the single 'alias' parameter. The description does not explain what 'alias' means or how it should be used, leaving the agent without necessary context to correctly invoke the tool.
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 returns server load, memory, and disk overview, which is a specific verb+resource. It distinguishes from sibling tools like ssh_gpu_status and ssh_service_status by naming the exact metrics covered.
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, exclusions, or scenarios where another sibling tool would be more appropriate.
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 this as read-only, idempotent, and non-destructive. The description adds value by specifying the exact information returned (user, hostname, kernel), which is beyond the annotation metadata. It does not contradict annotations, and the network connection implication is consistent with the openWorldHint.
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 sentence that directly states the action and the returned information, with no redundant words or filler. It is maximally concise while covering the core purpose.
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?
For a simple read-only tool with one parameter and an output schema, the description covers the primary action and result. However, it omits an explanation of the 'alias' parameter and any usage context, leaving gaps that force the agent to infer from the name or siblings. It is minimally adequate but not richly informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'alias' parameter with no description in the schema (coverage 0%). The tool description does not explain what 'alias' refers to or how to obtain valid values, relying purely on the parameter name and sibling tool context. This is insufficient compensation for the lack of schema documentation.
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 connects to a server and returns user, hostname, and kernel information, which is a specific verb+resource with concrete output. However, it does not explicitly differentiate from sibling tools like ssh_system_status, so it stops short of 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without mentioning exclusions, prerequisites, or sibling tool relations. This lacks the explicit context needed for an agent to choose between ssh_check and similar tools.
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?
The description adds the useful scope '当前 MCP 进程中的' (current MCP process), which is beyond what the annotations convey. However, it does not disclose side effects such as disconnecting active sessions or behavior when the tunnel is already stopped; the non-read-only and non-idempotent hints are already present in annotations.
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 a single, focused sentence with no filler and front-loads the action. It is appropriately concise, though the terseness leaves some behavioral details unaddressed.
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?
For a simple stop operation with annotations and an output schema, the description covers the core action and process scope. However, it omits practical details like how to obtain the tunnel_id or what the stopping action implies for existing connections, so an agent may need to infer these from sibling tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions '指定的隧道' (specified tunnel) and does not explain the tunnel_id parameter, its source, or how it should be formatted. With 0% schema description coverage, the agent receives no additional meaning beyond the bare string type in the input schema.
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 stops a specified SSH tunnel within the current MCP process, using a specific verb and resource. This distinguishes it from sibling tools like ssh_tunnel_start and ssh_tunnel_list, which are naturally associated with start and list 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 is provided on when to use this tool versus alternatives, such as deciding between stopping, starting, or listing tunnels. It also does not mention prerequisites like having an active tunnel or any exclusions.
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 description adds a specific behavioral detail that local targets may be overwritten if they already exist, which goes beyond the annotations' destructiveHint=true by explaining the overwrite condition. This is consistent with annotations and adds context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is structurally efficient. However, it is under-specified for a five-parameter tool, providing only a vague overview. It is not wordy but sacrifices critical information for brevity.
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?
With five parameters, annotations, and an output schema, the description covers only the basic download action and overwrite risk. It omits whether recursive downloads are supported, the purpose of preserve, or the role of alias, leaving significant gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters. It only alludes to 'local target' and 'download file' without clarifying the roles of remote_path, local_path, alias, preserve, or recursive. Parameter meanings are left entirely to name inference.
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 downloads files via SFTP, using a specific verb and resource. This distinguishes it from sibling tools like ssh_upload (upload) and ssh_execute (command execution).
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?
The description implies usage for downloading files from a remote server over SFTP, but does not explicitly state when to use it over alternatives or mention exclusions (e.g., directories). The sibling tool ssh_upload implies the opposite, but no explicit guidance is provided.
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 the tool as destructive and not read-only. The description adds that commands may change server state and requires intent confirmation, providing behavioral context beyond 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 one sentence with no unnecessary words, front-loading the purpose then adding a concise warning. Every word earns its place.
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?
The description covers the core purpose and safety warning, and the existence of an output schema addresses return values. However, it lacks parameter semantics and explicit usage alternatives, making it incomplete for an arbitrary command execution tool.
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?
The description provides no information about the parameters (alias, command, timeout_seconds). With 0% schema description coverage, the agent has no guidance on how to fill these fields, making the description entirely unhelpful for parameter semantics.
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 executes any remote command, which is a specific verb+resource. It distinguishes from sibling tools that handle specific operations like ssh_check or ssh_upload, making it the generic execution tool.
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?
The phrase 'any remote command' implies this is the catch-all execution tool, but it does not explicitly state when to use it versus siblings or provide exclusions. The warning about confirmation is a safety note, not a usage alternative.
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 read-only, idempotent, and non-destructive behavior. The description adds specific data fields returned (memory, utilization, temperature, power), which is useful context beyond the safety profile. 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 a single, front-loaded sentence with no filler. It efficiently communicates the tool's core function without unnecessary 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?
The description adequately covers the tool's function but omits essential context about the 'alias' parameter and how to discover valid aliases (likely via ssh_list_servers). For a simple tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'alias' is not explained in the description, and schema coverage is 0%. The description does not compensate for this gap, leaving ambiguity about whether alias refers to a server or GPU identifier.
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 returns structured NVIDIA GPU metrics (memory, utilization, temperature, power), which is specific and distinguishes it from sibling tools like ssh_system_status or ssh_service_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?
No guidance is provided on when to use this tool versus alternatives such as ssh_system_status or ssh_job_status. The agent must infer usage from the tool name and sibling context.
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 flag destructiveHint=true, and the description adds specific detail about what gets destroyed (scripts, logs, status files) and the condition (completed tasks). It does not discuss irreversibility or permissions, but the destructive annotation already signals the risk, so the added context 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?
The description is a single sentence that directly states the action and target with no unnecessary words. It is front-loaded and appropriately concise.
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?
Given the tool's simplicity (2 params, output schema present) and the destructive annotation covering safety, the description is mostly complete. It defines the scope (completed tasks) and the objects, which is enough for an agent to understand the basic operation. Minor gaps include behavior for active jobs or missing files, but the output schema likely handles error reporting.
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?
The input schema has 0% description coverage, and the description does not mention alias or job_id at all. The agent must rely purely on parameter names, which is insufficient for a remote SSH tool with required arguments.
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 action (delete) and the resources (scripts, logs, and status files) for completed tasks. This specific verb+resource distinction differentiates it well from sibling tools like ssh_job_status and ssh_cancel_job.
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?
The phrase '已完成任务' (completed tasks) implies it is used after jobs finish, but there is no explicit guidance on when to use it versus alternatives, nor any exclusions or recommended conditions. The usage is only implied by context.
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 indicate a non-read-only, non-idempotent operation with open-world side effects. The description adds valuable context that the tunnel binds only to 127.0.0.1, a security-relevant behavior. However, it does not mention conflict behavior if a tunnel already exists or whether authentication is required.
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, action-first sentence with no filler. It is appropriately sized for a simple tool and easy to parse.
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?
While the description clearly conveys the core action, it leaves important gaps: no parameter guidance, no mention of the required `alias` context, and no lifecycle note. The output schema may cover return values, but the input side remains under-specified for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for parameters, and the description does not explain the role of `alias`, `local_port`, `remote_host`, or `remote_port`. The only hint is that it creates local port forwarding, leaving `alias` and port semantics ambiguous.
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 uses the specific verb '创建' (create) with a clear resource '本地端口转发' (local port forwarding) and adds the constraint '仅监听 127.0.0.1' (listening only on 127.0.0.1). This distinguishes it from sibling tools like ssh_tunnel_stop and ssh_tunnel_list, and from general ssh_execute.
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?
The usage is implied from the tool name and sibling context, but the description does not state when to choose this tool over alternatives, nor any preconditions like needing an alias from ssh_list_servers. It provides no explicit exclusion 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, and non-destructive behavior. The description adds value by disclosing the specific outputs (status, process group, exit code, limited tail log), and the mention of 'limited' tail logs provides additional context about response size constraints. No contradiction with 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 a single, concise sentence that front-loads the core purpose and key output details. Every word contributes meaningful information, with no redundancy or filler.
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?
The tool has an output schema, annotations, and a rich set of sibling tools that provide context. However, the description is minimal and does not cover parameter usage, prerequisites (e.g., job must be running), or typical scenarios. It is adequate but leaves gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain individual parameters like alias, job_id, tail_lines, or max_log_bytes. Although the mention of 'tail logs' hints at tail_lines, it does not clarify parameter semantics, leaving the agent to rely on parameter names alone.
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 queries background job status, process group, exit code, and limited tail logs, using a specific verb and resource. This distinguishes it from siblings like ssh_job_list (list all jobs) and ssh_cancel_job, making its function unique and clear.
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?
The description implies usage (querying a specific job's status via job_id) but does not explicitly state when to use this tool versus alternatives like ssh_job_list or ssh_check. No when-not-to-use or alternative guidance is provided, leaving the agent to infer from the tool name and parameters.
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 mark this as destructive and non-read-only. The description adds the valuable context that after a waiting period (force_after_seconds) the task is force-terminated, providing meaningful behavioral detail beyond 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 a single, front-loaded sentence with no waste. It immediately states the core action and adds the timeout condition concisely.
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?
Given the tool has an output schema, return format is covered. The description covers the core cancellation behavior and timeout. It does not mention prerequisites like a running job or the meaning of alias, but given sibling context and annotations, the description is sufficiently complete for a simple destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It only hints at 'force_after_seconds' via the timeout phrase, but does not explain 'alias' or 'job_id' beyond what their names imply.
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 terminates a background task and force-ends it after a timeout. This is specific and distinguishable from siblings like ssh_job_status, ssh_job_list, and ssh_job_cleanup.
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?
The description implies it is used for cancelling a remote background job, and the timeout behavior suggests it can be used when a graceful stop is needed. However, it does not explicitly contrast with alternatives such as ssh_job_cleanup or state when not to use it.
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 description adds a meaningful scope constraint beyond the annotations: it lists only tunnels created by the current MCP process, not all system tunnels, and only active ones. This is a behavioral trait not captured by readOnlyHint, idempotentHint, or destructiveHint. It does not dwell on return format, but the output schema covers that.
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, front-loaded sentence that states exactly what the tool does with no redundancy. Every word earns its place, and it is appropriately concise for a zero-parameter list operation.
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 (no parameters, read-only annotations, and an output schema present), the description is complete. It conveys the core purpose and scope without needing to explain return values or additional caveats. The output schema handles return structure.
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 zero parameters, so per the rubric the baseline is 4. There are no parameter details to add, and the description makes no misleading claims about inputs.
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 action ('列出', meaning 'list') and the resource ('活动隧道', meaning 'active tunnels'), and further specifies 'created by the current MCP process'. This distinguishes it from sibling tools like ssh_tunnel_start and ssh_tunnel_stop, making the purpose unambiguous.
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 explicit guidance on when to use this tool versus alternatives. There is no mention of 'use this to view tunnels' or 'use ssh_tunnel_start/stop to manage them'. The usage is only implied by the tool's function.
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 mark the operation as read-only, non-destructive, and idempotent. The description adds that only explicit Host aliases are returned and only those available for MCP, which is valuable scoping behavior beyond 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 a single, focused sentence that starts with the action and communicates the essential scope. No filler or redundant information.
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 zero-parameter, read-only list tool with an output schema and safety annotations, the description fully covers the tool's purpose and scope. It doesn't need to explain return values or side effects.
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 zero parameters, so there is nothing to explain beyond what the schema already shows. The baseline of 4 applies because no parameter documentation is needed.
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 specifies a clear action (list) and resource (explicit Host aliases in ~/.ssh/config), and distinguishes this from sibling tools that execute, check, or upload files. It also includes the qualification 'available to MCP', which differentiates it from a generic config dump.
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 implies this tool is used to enumerate SSH server aliases that are compatible with other MCP SSH tools, providing clear context for its use. It does not explicitly name alternatives or exclusions, but the context is sufficient given the tool's simple read-only nature.
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:

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

Score Badge

Copy to your README.md:

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

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/yuyi-clip/ssh-mcp-server'

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