Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lms-ssh-client-mcp SSH into dev.example.com and show disk usage"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server designed for LM Studio, Claude Desktop, and other MCP-enabled LLM hosts. This server enables LLMs to securely SSH into remote servers, execute commands, list directories, and manage files (read, write, delete, create directories, rename files) over SFTP.
Persisted SSH Connections: Establish SSH sessions and maintain them in-memory, allowing consecutive tool calls on the same host without repeating credentials.
Remote Command Execution: Execute shell commands on the remote machine (ssh_execute_command).
Full SFTP File Manager:
List files and directories with formatted unix permissions, sizes, and timestamps (ssh_sftp_list_dir).
Read remote files up to 2MB securely (ssh_sftp_read_file).
Create, write, or update files (ssh_sftp_write_file).
Delete files (ssh_sftp_delete_file).
Create and delete directories (ssh_sftp_mkdir / ssh_sftp_rmdir).
Rename or move remote items (ssh_sftp_rename).
Flexible Authentication:
Authenticate using Username & Password.
Authenticate using private keys (either pass the raw key string or a local file path like ~/.ssh/id_rsa).
Zero-Config Fallback: If no credentials are specified, the server automatically looks for default keys in your local ~/.ssh/ directory (e.g. id_ed25519, id_rsa, id_ecdsa, etc.) to authenticate passwordlessly.
Graceful Shutdown: Automatically closes all active SSH connections when the LLM client stops the MCP server.
Related MCP server: ssh-mcp
Clone and Install Dependencies: Navigate to the directory and run:
npm installBuild the Server: Compile the TypeScript files into JavaScript:
npm run buildThere are two ways to load this MCP server in LM Studio:
mcp.json Configuration File (Recommended)You can directly add the configuration to your local LM Studio MCP configuration file (typically located at ~/.lmstudio/mcp.json on macOS/Linux).
Open ~/.lmstudio/mcp.json in your favorite editor:
nano ~/.lmstudio/mcp.jsonAdd the server entry to the mcpServers object:
{
"mcpServers": {
"lms-ssh-client-mcp": {
"command": "node",
"args": [
"/Users/ethan/desktop/projects/lms-ssh-client-mcp/dist/index.js"
]
}
}
}Save the file and restart LM Studio.
Open LM Studio.
Go to the Developer Tools tab (gear icon on the left sidebar / developer settings).
Scroll down to the Model Context Protocol (MCP) section.
Click Add Server and enter the following settings:
Name: lms-ssh-client-mcp
Type: stdio
Command: node
Arguments: ["/Users/ethan/desktop/projects/lms-ssh-client-mcp/dist/index.js"] (Make sure to use the absolute path to your compiled dist/index.js)
Click Save to start the server.
To use this server with Claude Desktop, add it to your claude_desktop_config.json (located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"ssh-client": {
"command": "node",
"args": ["/Users/ethan/desktop/projects/lms-ssh-client-mcp/dist/index.js"]
}
}
}The server exposes the following tools to the LLM:
ssh_connectConnect to a remote server and get back a connectionId.
Arguments:
host (string, required): Hostname or IP address.
port (number, default: 22): Port number.
username (string, required): SSH username.
password (string, optional): SSH password.
privateKey (string, optional): Raw SSH private key text OR a path to the local key file (e.g., ~/.ssh/id_rsa).
passphrase (string, optional): Decryption passphrase for the private key if it is encrypted.
readyTimeout (number, default: 20000): Connection timeout in milliseconds.
ssh_execute_commandExecute shell commands on the remote machine.
Arguments:
connectionId (string, required): The ID returned by ssh_connect.
command (string, required): The shell command to run (e.g. cd /var/www && ls -la && tail -n 20 error.log).
timeoutMs (number, default: 30000): Command execution timeout.
Environment state (like current working directorycd) is not preserved between individual ssh_execute_command tool calls. To perform multiple operations in the same folder or with the same variables, run them as a combined command using standard shell operators (e.g., cd /app && npm install && npm run build).
ssh_list_connectionsLists all active connections (shows connectionId, host, username, port, connectedAt).
Arguments: None.
ssh_close_connectionTerminate an active SSH connection cleanly.
Arguments:
connectionId (string, required): Connection to close.
ssh_sftp_list_dirInspect folders on the remote system using SFTP.
Arguments:
connectionId (string, required)
path (string, required): Remote path to inspect (e.g., /etc or .).
ssh_sftp_read_fileRead remote files securely.
Arguments:
connectionId (string, required)
path (string, required): File path to read.
encoding (string, default: "utf8"): Encoding of the content (use "base64" for binary files).
ssh_sftp_write_fileWrite/upload files to the remote server.
Arguments:
connectionId (string, required)
path (string, required): File path to write.
content (string, required): File content text or base64-encoded binary.
encoding (string, default: "utf8")
ssh_sftp_delete_fileDelete files on the remote server.
Arguments:
connectionId (string, required)
path (string, required): File path to delete.
ssh_sftp_mkdir / ssh_sftp_rmdirCreate directories or delete empty directories.
Arguments:
connectionId (string, required)
path (string, required): Directory path.
ssh_sftp_renameRename or move a remote file or folder.
Arguments:
connectionId (string, required)
oldPath (string, required)
newPath (string, required)
Since stdio is used for MCP JSON-RPC communication, do not log to stdout (console.log) in your code as it will break the protocol parser.
All log messages inside this server are written to stderr (console.error), which will appear in your LLM client's debug logs (e.g., in LM Studio's MCP log view).
Close an active SSH connection.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID of the connection to close |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavior such as idempotency, error handling for invalid connections, or state changes. Minimal beyond name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct, and front-loaded. Every word is purposeful, though somewhat under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately states the purpose but omits implications like freeing resources or impact on other operations. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for connectionId. The tool description adds no additional parameter context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Close' and resource 'active SSH connection', clearly distinguishing it from sibling tools like ssh_connect (open) and ssh_execute_command (execute commands). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description merely states what it does, not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a remote SSH server. Returns a session ID to be used for subsequent commands and files. If neither password nor privateKey are specified, this tool will attempt to use default keys in your ~/.ssh directory. If a file path is provided in privateKey, it will be loaded from disk.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Remote host name or IP address | |
| port | No | Port number (default: 22) | |
| username | Yes | Username for connection | |
| password | No | Password (if using password authentication) | |
| pw | No | Alias for password (helpful fallback for small LLMs) | |
| privateKey | No | Raw private key content OR a local path (e.g. '~/.ssh/id_rsa') to the key | |
| passphrase | No | Passphrase to decrypt the private key (if encrypted) | |
| readyTimeout | No | Connection timeout in milliseconds (default: 20000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return value (session ID), authentication fallback, and that privateKey can be a file path. Lacks details on error handling or connection persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, return value, authentication methods, and default behavior adequately for a connection tool with 8 parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by explaining privateKey accepts path or content, and mentions 'pw' alias. Schema coverage is 100%, so baseline is 3; description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool connects to a remote SSH server and returns a session ID, distinguishing it from sibling tools that perform other SSH operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on authentication methods (password, privateKey, default keys) and explains fallback behavior, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a command on the remote host via SSH. Note: Shell environment state like current directory (cd) is NOT preserved between distinct tool calls. To run multiple commands in the same path, chain them (e.g. 'cd /var/www && ls -la').
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| command | Yes | The command line string to run on the remote shell | |
| timeoutMs | No | Execution timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full behavioral disclosure. It highlights a non-obvious limitation: shell environment state (e.g., current directory) is not preserved. This is valuable for correct usage. It could also mention output format or error handling, but the disclosed behavior is critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the core purpose, and the second provides an essential behavioral note. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the non-preservation of shell state, which is important, but it omits details about output (e.g., what is returned after command execution) and error handling (e.g., what happens on timeout). For a command execution tool, the output is a key aspect not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the input schema. The tool description adds no additional semantic detail about parameters beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a command on the remote host via SSH.' It uses a specific verb and resource, and the context from sibling tools (SSH connection management and SFTP file operations) distinguishes this tool from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a crucial usage guideline: shell state is not preserved between calls, and it suggests chaining commands. However, it does not explicitly mention when not to use this tool (e.g., for file transfers) or compare to siblings, though the sibling list implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active SSH connection IDs and details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states 'active SSH connection IDs and details' but does not mention if the operation is read-only, has any side effects, or requires authentication. The lack of detail on what 'details' entails is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word serves a purpose with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters, the description is incomplete for a list tool. It does not specify what 'details' are returned (e.g., host, user, port, status), nor does it confirm the scope (all connections or only those owned by the user). Without an output schema, the description should provide these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. According to guidelines, baseline is 4 for 0 params. The description does not add parameter info, but none is needed. However, it could have mentioned that no parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all active SSH connection IDs and details.' It specifies the verb (list) and resource (active SSH connections), and the sibling tools cover different operations (close, connect, execute, SFTP), so this tool is uniquely positioned as the listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing active connections but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions. Given the sibling tools are distinct, the absence of explicit when-to-use is acceptable but not optimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file on the remote server using SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| path | Yes | Remote file path to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'delete a file' but does not mention whether the operation is permanent, what happens if the file doesn't exist, or required permissions. The destructive nature is inferred but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no unnecessary words. Every part is relevant and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema and two well-documented parameters, the description is largely adequate. However, it fails to mention that a valid connection from ssh_connect is required, and it does not describe success/failure behavior or error cases. With siblings present, a small improvement would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both connectionId and path have descriptions). The tool description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (file), and the method (SFTP). It is a specific verb+resource combination that distinguishes it from siblings like ssh_sftp_rmdir (for directories) or ssh_sftp_read_file (for reading).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting files via SFTP but does not explicitly state when to use it versus alternatives (e.g., rmdir for directories) or prerequisites (e.g., must have an active connection from ssh_connect). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories on the remote server using SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| path | Yes | Remote path to list (e.g., '.', '/var/log') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states 'list'. Does not disclose behavioral traits such as idempotency, error handling, or whether it requires an active connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, but could be more informative about return format. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not specify what is returned (e.g., just filenames or metadata). Incomplete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters (connectionId, path) with clear examples. Description adds no extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and resource 'files and directories on the remote server', distinguishing it from siblings like ssh_sftp_read_file or ssh_sftp_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites or context where this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a directory on the remote server using SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| path | Yes | Remote directory path to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether the operation fails if parent directory doesn't exist, permissions required, or if it creates intermediate directories. It simply restates the action without added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no superfluous words. However, it is slightly terse and could be expanded with brief usage hints without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with well-documented parameters and no output schema, the description is minimally adequate. However, it lacks context about valid paths or connection state, making it less complete for an agent unfamiliar with the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no further meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a directory') and the method ('using SFTP') on a remote server. It distinguishes from siblings like ssh_sftp_rmdir (remove directory) and ssh_sftp_delete_file (delete file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., ssh_execute_command with mkdir). No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file on the remote server using SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| path | Yes | Remote path of the file to read | |
| encoding | No | Encoding to use (e.g. 'utf8', 'base64' for binary files). Default is 'utf8'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It implies a read operation, but doesn't explicitly state it's non-destructive or safe, nor address potential size limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with the core action and context (remote server, SFTP). No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description doesn't mention return type (string with encoding) or how to handle binary files. The schema hints at encoding, but description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (connectionId, path, encoding) with descriptions. The tool description adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a file via SFTP, with a specific verb ('Read') and resource ('file on remote server'). It distinguishes well from sibling tools like ssh_sftp_write_file and ssh_sftp_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., ssh_execute_command for reading with cat). It doesn't mention prerequisites like an active session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename or move a file or directory on the remote server using SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| oldPath | Yes | Current remote path of the file or directory | |
| newPath | Yes | New remote path for the file or directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action without disclosing behavioral traits such as overwrite behavior, error handling, or permission requirements. Since no annotations are provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose, with no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but sufficient for a simple rename operation. However, it lacks details about return values, error behavior, and potential side effects, which could be important for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptive names and descriptions. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (rename or move), the resource (file or directory), and the context (remote server using SFTP). It effectively distinguishes this tool from siblings like delete, list, or read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for renaming or moving, which is self-explanatory from the name. However, it does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites like an active connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an empty directory on the remote server using SFTP.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| path | Yes | Remote directory path to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavior for non-empty directories, required permissions, or error scenarios. Only states 'empty directory' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (8 words), but too brief; lacks important details such as the implication of 'empty' and connection prerequisite. Could expand without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 required params and no output schema, the description should cover prerequisites (active connection), constraints (directory must exist and be empty), and failure behavior. It covers only the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning, only the 'empty directory' constraint which is behavioral rather than parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove'), the target ('empty directory'), and the method ('using SFTP'). It distinguishes from sibling tools like ssh_sftp_mkdir and ssh_sftp_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., for non-empty directories). No mention of prerequisites like an active connection from ssh_connect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a file on the remote server using SFTP. Creates the file if it does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The session ID returned by ssh_connect | |
| path | Yes | Remote path of the file to write | |
| content | Yes | Content to write | |
| encoding | No | Encoding of the content (e.g. 'utf8', 'base64' for binary data). Default is 'utf8'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the file is created if it does not exist, but critically omits whether existing files are overwritten or appended. It also does not disclose behavior around encoding (though schema covers default), permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no fluff, and immediately conveys the core functionality. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema and no annotations, the description is incomplete. It lacks information about return values (success/failure), error handling, idempotency, or size constraints. The note about file creation is helpful but insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters described), so baseline is 3. The description adds a behavioral note about file auto-creation, which is not in the schema, but does not elaborate on parameter-specific nuances like path formats or encoding usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes content to a file on a remote server using SFTP, and notes that it creates the file if it does not exist. This is a specific verb+resource structure that distinguishes it from siblings like ssh_sftp_read_file or ssh_sftp_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., ssh_execute_command for shell-based file writing) or when not to use it. It does not mention prerequisites like an active connection or constraints like file size limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0ssh_close_connectionssh_connectssh_execute_commandssh_list_connectionsssh_sftp_delete_filessh_sftp_list_dirssh_sftp_mkdirssh_sftp_read_filessh_sftp_renamessh_sftp_rmdirssh_sftp_write_fileEach tool has a clearly distinct purpose: connection management, command execution, and SFTP operations are all separated. No two tools overlap in functionality, and descriptions clearly differentiate them.
All tools follow a consistent 'ssh_' prefix for SSH operations and 'ssh_sftp_' for SFTP operations. Verbs are uniform (e.g., connect, execute, list, read, write), making the naming pattern predictable and easy to parse.
With 11 tools, the set is well-scoped for an SSH client, covering connection lifecycles, command execution, and comprehensive SFTP file operations. Neither too few nor too many for the domain.
The tool set covers all essential SSH client operations: connect/disconnect, execute commands, and full SFTP CRUD (list, read, write, delete, rename, mkdir, rmdir). Minor gaps like directory uploads are compound operations, not necessary for basic coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mr365truck/LMS-SSH-Client-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
