my-mcp-ssh

by ffpy

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
Disambiguation5/5
Each tool targets a distinct action: connect/disconnect manage sessions, list_sessions enumerates them, execute runs commands, and upload/download transfer files. There is no overlap or ambiguity between tool purposes.
Naming Consistency5/5
All tool names follow a clear imperative verb style, using lowercase with underscores. The names are concise and predictable, with list_sessions being the only verb_noun form, which is appropriate for a listing operation.
Tool Count5/5
The server provides 6 tools, which is well-scoped for an SSH MCP server. Each tool serves a core function (session management, command execution, file transfer) without unnecessary bloat, fitting the typical 3-15 tool range.
Completeness5/5
The tool surface covers the full lifecycle of SSH interactions: connect, disconnect, session listing, command execution, and file upload/download. No obvious gaps exist for standard SSH usage, making the set complete for its stated purpose.
Average 3.5/5 across 6 of 6 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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
This repository is licensed under Apache 2.0.
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?
With no annotations, the description carries the full burden of disclosing behavior. It does not mention potential side effects (e.g., overwriting existing local files), error conditions, or access requirements. The 'Returns' line is vague and adds no operational detail.
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 concise and uses a clear Args/Returns structure, but it is thin and the Returns section is uninformative ('Dictionary containing download status information'). It is not bloated, yet it under-delivers on substance.
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 no output schema and no annotations, and the description does not explain what the returned dictionary contains, how to verify success, or how this tool relates to 'upload'. While the tool is simple, the missing context leaves the agent uncertain about invocation and result handling.
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. However, it merely restates parameter names with generic descriptors ('Session ID', 'Remote file path', 'Local file path') that add little beyond the schema's own titles. No constraints, formats, or relationships are explained.
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 'Download file from SSH server' with clear verb and resource. The Args section clarifies the direction (remote to local) via 'remote_path' and 'local_path', distinguishing it from the sibling 'upload' tool.
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. There is no mention of prerequisites (e.g., active session), nor any exclusion or comparison with the sibling 'upload' tool.
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, the description carries the full burden for behavioral disclosure. It only states that it uploads a file and returns a dictionary, but omits critical traits such as whether the remote file is overwritten, whether directories are created, authentication requirements, or error handling. This is insufficient for a mutation 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 concise and well-structured with clear Args and Returns sections. Every sentence earns its place, though the parameter descriptions could be more substantive. Overall, it is appropriately sized and front-loaded.
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 is simple but the description omits essential context such as the requirement of an active session (prerequisite from connect), potential side effects, and error behavior. With no annotations and no output schema, the description is incomplete for an AI agent to use reliably.
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 Args section lists all three parameters but the descriptions are tautological (e.g., 'local_path: Local file path'), adding little meaning beyond the parameter names. Since the schema has 0% description coverage, the tool description should compensate but does not provide any additional detail about formats, constraints, or behavior.
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 action and resource: 'Upload file to SSH server'. This is a specific verb+resource construction that unambiguously distinguishes it from siblings like download and execute.
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. It does not mention that a session must be active (via connect) or that download is the counterpart for retrieval. The purpose is implied but no explicit usage context is given.
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 the full burden of behavioral disclosure. It only mentions returning a disconnection status but fails to disclose potential side effects such as terminating the session, closing active channels, or behavior when the session ID is invalid.
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 brief and front-loaded with the purpose, followed by a structured Args/Returns format. It contains no wasted words, though it could include more detail in other dimensions.
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 tool, the description includes a return status but lacks behavioral context and usage guidance. Given the absence of annotations and output schema, the agent has limited information about the tool's side effects and lifecycle implications.
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 merely restates the parameter name ('session_id: Session ID to disconnect') without adding meaningful context beyond the schema. It does not explain where to obtain the session ID or any constraints on its format.
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 ('Disconnect from SSH server') with a specific verb and resource, making it easy to distinguish from sibling tools like connect, execute, and list_sessions.
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 purpose implies the tool should be used to end an SSH session, but there is no explicit guidance on when to use it versus alternatives or prerequisites like having an active session. The context is implied rather than stated.
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, the description carries the full burden of behavioral disclosure. It only says it lists sessions and returns a list of information, but does not disclose whether this is a read-only operation, any side effects, authentication requirements, or what specific information is included beyond 'information'. This is minimal and leaves the agent uncertain about the tool's behavior.
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 concise, front-loaded with the action, and every sentence earns its place. The 'Returns' line is somewhat redundant but not harmful, and the overall structure is clear and efficient.
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 zero-parameter tool, the description is adequate but leaves gaps. It does not explain what 'information' is included in the returned list, and without an output schema, this is a notable omission. It also lacks usage context relative to sibling tools, making the description incomplete for an agent trying to decide when to invoke it.
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?
This tool has zero parameters, so the schema provides no information to add value. The description correctly does not need to detail parameters, and a baseline of 4 is appropriate for a parameterless 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 states a specific verb ('List') and resource ('all active SSH sessions'), making it completely clear what the tool does. It is distinct from sibling tools which perform actions like connect, disconnect, execute, upload, and download.
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. It does not mention prerequisites, such as needing an active connection, or whether to use this before connecting or after sessions are established. The description simply states what it does without contextual usage advice.
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, the description carries the burden of behavioral disclosure. It lists authentication methods (password/key) and says it returns connection status, but does not explain session lifecycle, side effects, or failure modes.
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 organized into an Args list and a Returns line, making it easy to scan. It is appropriately sized for the number of parameters, though it could be tightened by removing the word 'optional' repetition.
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 six parameters and no output schema, the description covers the parameters and return status adequately. However, it lacks context on connection behavior (e.g., persistent sessions, timeouts, or how to use the returned status).
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%, and the description fully compensates by listing all six parameters with clear explanations of each (host, port, username, password, key_path, key_passphrase). This provides essential meaning beyond the bare 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 'Connect to SSH server', using a specific verb and resource. It naturally distinguishes itself from sibling tools like disconnect, execute, and list_sessions.
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 by listing connection parameters and return status, but it does not explicitly state when to use this tool over alternatives or mention preconditions like needing an existing session.
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?
No annotations are provided, so the description carries the burden. It discloses the core behavior (executing a command), the return format (stdout/stderr and exit status), and default timeout. However, it does not warn about potential destructive side effects or prerequisites like an active session, which is a significant gap for an execution tool.
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 efficiently structured as a docstring with Args and Returns sections. Every line adds value, with no redundant information and clear separation of parameter details.
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 tool's purpose, parameters, and return value well. Missing usage prerequisites (e.g., active session) and safety warnings, but for a straightforward execution tool with a simple schema, it is largely complete.
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?
Input schema has 0% description coverage, so the description fully compensates by explaining all four parameters with purpose and defaults. It adds meaningful context like 'input string to provide' and 'timeout in seconds' beyond what the schema offers.
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?
Description states 'Execute command on SSH server' with a specific verb and resource. Clearly distinguishes from sibling tools like connect, disconnect, upload, and download, which handle session management and file transfer.
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 clearly implies when to use this tool: when you need to run a command on an existing SSH session. It provides concrete context (session_id, command, timeout) but does not explicitly exclude alternatives or mention 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.

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:

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

Score Badge

Copy to your README.md:

[![my-mcp-ssh MCP server](https://glama.ai/mcp/servers/ffpy/my-mcp-ssh/badges/score.svg)](https://glama.ai/mcp/servers/ffpy/my-mcp-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/ffpy/my-mcp-ssh'

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