Allows managing tmux sessions on remote servers, including creating, listing, attaching, and capturing output from persistent terminal sessions.
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., "@mcp-ssh execute 'df -h' on my server"
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.
English Version (README-EN.md)
这是一个基于 MCP (Model Context Protocol) 的 SSH 工具，它能让 AI 模型通过标准化接口访问和管理 SSH 连接。
简单来说，它让 AI 助手能够执行各种 SSH 操作，如连接服务器、执行命令、管理文件等，无需用户手动输入复杂的命令或切换到终端。
连接管理：创建、获取、列表、更新、删除 SSH 连接
命令执行：执行单条命令、复合命令、后台任务
tmux 会话管理：创建、获取、列表、发送按键、捕获输出
文件操作：上传、下载、查看文件内容
进程管理：检测阻塞进程、智能等待、超时处理
安全控制：密码/密钥认证、超时控制、错误处理
以下是 SSH MCP 工具的一些核心特点：
智能命令执行：自动检测并等待阻塞进程，避免会话卡死
tmux 集成：完整支持 tmux 会话管理，实现持久化终端会话
复合命令支持：智能处理包含 && 和 ; 的复合命令
实时反馈：命令执行状态实时更新，支持长时间运行的任务
错误恢复：自动处理断线重连、超时等异常情况
安全可靠：支持多种认证方式，保护敏感信息
通过简单的自然语言指令，AI 可以帮助你完成上述所有操作，无需手动编写复杂的 SSH 命令或在终端中执行操作。
Related MCP server: ssh-mcp-server
Python 3.11+（必需）
访问 Python 官网
下载并安装 Python 3.11 或更高版本
重要：安装时请勾选"Add Python to PATH"选项
安装完成后请重启电脑，确保环境变量生效
Node.js 和 npm
访问 Node.js 官网
下载并安装 LTS（长期支持）版本
安装时选择默认选项即可，安装包会同时安装 Node.js 和 npm
Git
访问 Git 官网
下载并安装 Git
安装时使用默认选项即可
tmux (远程服务器需要)
在远程服务器上安装 tmux
对于 Ubuntu/Debian: sudo apt-get install tmux
对于 CentOS/RHEL: sudo yum install tmux
git clone https://github.com/shuakami/mcp-ssh.git
cd mcp-ssh
npm install
npm run build⚠️ 重要提示：安装后请不要删除克隆或解压的文件，插件需要持续访问这些文件！
npm run build根据你的操作系统，按照以下步骤配置 MCP：
在 Cursor 中，打开或创建 MCP 配置文件：C:\\Users\\你的用户名\\.cursor\\mcp.json
注意：请将 你的用户名 替换为你的 Windows 用户名
添加或修改配置如下：
{
"mcpServers": {
"ssh-mcp": {
"command": "pythonw",
"args": [
"C:/Users/你的用户名/mcp-ssh/bridging_ssh_mcp.py"
]
}
}
}⚠️ 请注意:
将
你的用户名替换为你的 Windows 用户名确保路径正确指向你克隆或解压的项目目录
路径应该反映你将项目文件放置的实际位置
不要删除克隆或解压的文件夹，这会导致 MCP 无法正常工作
在 Cursor 中，打开或创建 MCP 配置文件：/Users/你的用户名/.cursor/mcp.json
注意：请将 你的用户名 替换为你的 macOS 用户名
添加或修改配置如下：
{
"mcpServers": {
"ssh-mcp": {
"command": "python3",
"args": [
"/Users/你的用户名/mcp-ssh/bridging_ssh_mcp.py"
]
}
}
}⚠️ 请注意:
将
你的用户名替换为你的 macOS 用户名确保路径正确指向你克隆或解压的项目目录
路径应该反映你将项目文件放置的实际位置
不要删除克隆或解压的文件夹，这会导致 MCP 无法正常工作
在 Cursor 中，打开或创建 MCP 配置文件：/home/你的用户名/.cursor/mcp.json
注意：请将 你的用户名 替换为你的 Linux 用户名
添加或修改配置如下：
{
"mcpServers": {
"ssh-mcp": {
"command": "python3",
"args": [
"/home/你的用户名/mcp-ssh/bridging_ssh_mcp.py"
]
}
}
}⚠️ 请注意:
将
你的用户名替换为你的 Linux 用户名确保路径正确指向你克隆或解压的项目目录
路径应该反映你将项目文件放置的实际位置
不要删除克隆或解压的文件夹，这会导致 MCP 无法正常工作
配置好之后，重启 Cursor 编辑器，它会自动启动 MCP 服务。然后你就可以开始使用了。
在 Cursor 编辑器中，使用 AI 助手创建新的 SSH 连接：
请帮我创建一个新的 SSH 连接，连接到我的服务器AI 助手会引导你提供以下信息：
主机地址（IP 或域名）
端口号（默认 22）
用户名
认证方式（密码或密钥）
其他可选配置（超时时间、密钥路径等）
连接创建后，你可以通过以下命令测试连接：
请帮我测试刚才创建的 SSH 连接请在服务器上执行 ls -la 命令AI 助手会：
检查现有 SSH 连接
执行命令并返回结果
格式化输出以提高可读性
请创建一个新的 tmux 会话并运行 top 命令AI 助手会：
创建新的 tmux 会话
在会话中执行 top 命令
返回会话 ID 供后续使用
请帮我查看 /var/log/syslog 文件的最后 100 行AI 助手会：
检查文件权限
使用适当的命令读取文件
格式化并返回内容
SSH MCP 工具内置了智能的阻塞检测机制：
自动检测交互式程序（如 vim、nano）
识别后台运行的阻塞进程
支持设置等待超时时间（最长10分钟）
提供强制执行选项（使用 force 参数）
支持执行包含 && 和 ; 的复合命令：
智能拆分和执行多个命令
保持命令执行顺序
提供详细的执行状态
支持错误处理和回滚
完整的 tmux 会话管理支持：
创建和管理持久化会话
支持发送按键序列
实时捕获会话输出
智能处理会话状态
为了更好地使用 SSH MCP 工具与远程服务器协作，建议在 Cursor 中添加以下 CursorRules 设置：
在**需要、或可能需要用户协助的**ssh任务时，可创建tmux，一个可共享的终端会话，并直接**告诉用户**可以通过什么命令链接到tmux来和你协作（不要在mcp内告诉用户，你应该输出出来）。然后再开始你的任务。
**你必须在tmux内进行任务。可以使用tmux send-keys相关命令，mcp会自动返回当前运行的命令和上一个运行的命令的结果。**
你应该先查看现有的tmux窗口再做决定。
**注意：在命令运行时必须耐心等待（sleep命令）当前命令，不要/同时/后台/继续执行下一个任务/命令。**
在用户没有明确要求时，你不应该创建帮助文件或者指南/报告文件。尤其是用户在找你帮忙的时候，你应该直接说出来。添加此设置后，AI 助手将能够更智能地处理 SSH 任务，特别是在需要用户协作的场景中，可以创建共享的 tmux 会话，让远程操作更加高效和透明。
本工具基于 MCP (Model Context Protocol) 标准实现，作为 AI 模型与 SSH 服务之间的桥梁。它使用 node-ssh 作为底层 SSH 客户端，并通过 Zod 进行请求验证和类型检查。
主要技术组件包括：
SSH 客户端：负责建立和维护 SSH 连接，支持密码和密钥认证
tmux 管理器：处理 tmux 会话的创建、管理和交互
命令执行系统：支持单命令、复合命令的执行，并提供阻塞检测
进程监控：实时检测进程状态，避免会话卡死
文件传输：支持上传和下载功能，处理各种文件类型
每个 SSH 操作都被封装为标准化的 MCP 工具，接收结构化参数并返回格式化结果。所有远程命令都经过处理，以确保以人类可读的格式呈现，使 AI 模型能够轻松理解命令执行结果。
欢迎提交 Issue 和 Pull Request！在提交之前，请：
查看现有的 Issue 和 PR
遵循项目的代码风格
添加适当的测试用例
更新相关文档
本项目采用 ISC 许可证 - 详见 LICENSE 文件
If this project helps you, please give it a Star ⭐️ (｡♥‿♥｡)
您也可以在 Docker 容器中运行此工具。这是推荐的使用方式，因为它可以避免与您的本地环境产生任何潜在的冲突。
构建 Docker 镜像:
docker build -t mcp-ssh .运行 Docker 容器 (附带数据持久化):
为了确保您的连接配置和凭证在容器重启后不丢失，我们强烈建议您使用 Docker 数据卷 (Volume)。
# (首次运行前) 创建一个数据卷来存储数据
docker volume create mcp-ssh-data
# 运行容器，并将数据卷挂载到容器的 /root/.mcp-ssh 目录
# 同时，我们仍然建议挂载您本地的 .ssh 目录以使用现有密钥
docker run -it -v mcp-ssh-data:/root/.mcp-ssh -v ~/.ssh:/root/.ssh mcp-ssh在 Windows 上，请使用 %USERPROFILE%\.ssh 代替 ~/.ssh:
docker run -it -v mcp-ssh-data:/root/.mcp-ssh -v %USERPROFILE%\.ssh:/root/.ssh mcp-sshExecutes a command in the background on a remote server at a specified interval.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| command | Yes | ||
| interval | No | ||
| cwd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions 'background' and 'interval' but does not specify whether the command runs repeatedly or just once, how output is handled, or if a task ID is returned. Minimal disclosure earns a score of 2.
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 sentence, which is concise, but it lacks structure and essential details. It is not as helpful as it could be, scoring a 3 for being adequate but not well-crafted.
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 tool has four parameters, no output schema, and no annotations, the description is incomplete. It omits key behavioral details (e.g., interval semantics, cwd role, return value) and does not cover all aspects needed for correct invocation.
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 0%, and the description provides no explanation of the four parameters (connectionId, command, interval, cwd). The tool's purpose vaguely hints at 'command' and 'interval', but no semantic detail is given for any parameter.
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 what the tool does: execute a command in the background on a remote server with an interval. However, it does not differentiate from the sibling tool 'executeCommand', which likely runs commands in the foreground. A score of 4 reflects clear purpose but lack of sibling distinction.
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 usage guidelines are provided. The description does not indicate when to use this tool over 'executeCommand' or other alternatives, nor does it mention prerequisites like an active connection. This is a significant gap for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Downloads multiple files from a remote server.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| files | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states basic function; lacks behavioral details like synchronicity, overwrite behavior, error handling, or side effects.
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 at the cost of missing critical information. No fluff, but insufficient for a tool with 2 parameters and no schema descriptions.
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 no output schema and 0% schema description coverage, the description is too sparse. Does not cover return values, error conditions, or dependency on connection state.
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 coverage is 0%, and the description adds no extra meaning to parameters. connectionId and files fields remain unexplained; localPath optionality is not clarified.
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 'Downloads multiple files from a remote server' clearly states the verb (downloads), resource (multiple files), and source (remote server). It implicitly differentiates from the sibling downloadFile which handles single files.
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 like downloadFile. No prerequisites (e.g., connection must exist) or context for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uploads multiple local files to a remote server.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| files | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a write operation but does not disclose behavior such as overwrite policy, error handling, partial success, or permission requirements. The minimal description lacks behavioral transparency.
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 sentence with no redundant words. It is front-loaded and to the point.
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 annotations and output schema, the description should provide more context about the connectionId (required), success indicator, error scenarios, and details about batch behavior. It is insufficient for a batch operation 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 description coverage is 0%, meaning the description adds no parameter info beyond the schema. The schema defines connectionId and files array with localPath/remotePath, which is self-explanatory. The description adds no extra meaning, but the schema is clear, 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 tool uploads multiple local files to a remote server. The verb 'Uploads' and resource 'local files to a remote server' are specific. It distinguishes from sibling tools like 'uploadFile' (singular) and 'batchDownloadFiles' (download direction). However, it does not explicitly contrast with 'uploadFile' or mention when to prefer batch over single.
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 (e.g., uploadFile). No prerequisites, context, or exclusions provided. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closes an active SSH tunnel.
| Name | Required | Description | Default |
|---|---|---|---|
| tunnelId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the action without disclosing side effects, authorization needs, or behavior on invalid input (e.g., tunnel not found).
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, clear sentence with no unnecessary words. It is appropriately sized for the tool's simplicity.
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 tool's low complexity (one parameter, no output schema), the description is minimally adequate but lacks context on error conditions, required state (tunnel must be active), and return behavior.
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 has 0% description coverage for the only parameter 'tunnelId'. The description does not explain what tunnelId is or where to obtain it, failing to compensate for the schema gap.
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 'Closes an active SSH tunnel' uses a specific verb ('closes') and resource ('active SSH tunnel'), clearly distinguishing it from siblings like 'createTunnel' and 'listTunnels'.
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 when to use (to close a tunnel) but provides no explicit guidance on prerequisites, when not to use, or alternatives. Usage is straightforward but lacks detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Establishes a new SSH connection to a server.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| port | No | ||
| username | Yes | ||
| password | No | ||
| privateKey | No | ||
| passphrase | No | ||
| name | No | ||
| rememberPassword | No | ||
| tags | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not explain behaviors such as connection failure handling, state persistence (implied by 'name' and 'rememberPassword' parameters), security implications, or whether the connection remains open. The single sentence is insufficient for a tool with side effects.
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 brief sentence, which is concise and front-loaded. However, for a tool with 9 parameters and significant behavior, it may be too terse. Still, it does not contain unnecessary 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 tool's complexity (9 parameters, no output schema, no annotations), the description is severely incomplete. It fails to mention return values, error conditions, or how the connection state is managed. Agents cannot effectively use this tool based solely on the description.
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?
With schema coverage at 0%, the description provides zero explanation of the 9 parameters (e.g., distinction between password and privateKey, purpose of tags, default for port). The description does not compensate for the missing schema descriptions.
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 ('Establishes') and resource ('SSH connection to a server'). It is specific and distinct from sibling tools like 'getConnection' (retrieve) and 'disconnect' (terminate). No tautology or 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?
The description offers no guidance on when to use this tool, prerequisites (e.g., network access, credentials), or when to use alternatives (e.g., 'createTunnel' for tunneled connections). Agent is left uninformed about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates an SSH tunnel (port forwarding).
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| localPort | Yes | ||
| remoteHost | Yes | ||
| remotePort | Yes | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description should disclose side effects and lifecycle. It only states creation, omitting that the tunnel persists until closed, potential port conflicts, or that it runs in background.
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?
Extremely concise (6 words) but insufficient for a 5-parameter tool. Sacrifices necessary detail for brevity.
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?
Incomplete for complexity: no output schema, no annotations, 5 parameters unexplained. Absent information about success indicators, errors, or what happens after creation.
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 0%, yet the description adds no parameter information. Even basic explanations for connectionId, localPort, remoteHost, remotePort are missing, forcing agents to infer from names.
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 'Creates' and the resource 'SSH tunnel' with parenthetical detail 'port forwarding'. It distinguishes from siblings like closeTunnel and listTunnels.
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. Does not mention prerequisites (e.g., need an existing connection) or instructions to use closeTunnel to tear down.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a saved SSH connection.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool performs a deletion (destructive action), but without annotations, it fails to detail side effects (e.g., permanent removal, impact on active sessions) or any required permissions.
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 short sentence with no unnecessary words, but it is too brief to be fully informative. It sacrifices completeness for brevity.
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 no output schema, no annotations, and a single parameter, the description should provide more context about return values, error handling, and where to find connectionId. It is insufficient for an agent to use correctly without external knowledge.
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 single parameter 'connectionId' is not described. With 0% schema description coverage, the description should explain what the ID represents and how to obtain it, but it provides no additional context beyond the parameter name.
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 ('Deletes') and the resource ('a saved SSH connection'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like getConnection or listConnections.
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 is provided on when to use this tool versus alternatives (e.g., disconnect, closeTunnel). There is no mention of prerequisites, such as needing an active connection or the consequences of deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnects an active SSH connection.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions 'disconnects' (a mutation) but does not disclose side effects, error conditions (e.g., invalid connectionId), or consequences like terminated processes. Insufficient behavioral detail.
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 sentence with no superfluous words. It is front-loaded with the core action and resource, making it highly 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?
Given the tool's simplicity (one required parameter, no output schema), the description covers the basic purpose. However, it omits error conditions or prerequisites, leaving room for improvement in completeness.
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 0%, and the description does not elaborate on the 'connectionId' parameter. While the name is self-explanatory, no additional semantics (e.g., format, source) are provided, failing to compensate for the lack of schema documentation.
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 (disconnects) and the resource (active SSH connection). It distinguishes itself from sibling tools like 'connect' (opposite function) and 'closeTunnel' (specific to tunnels), leaving 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 explicit guidance on when to use this tool versus alternatives, such as 'closeTunnel' or 'deleteConnection'. The context is implied but not stated, making it adequate but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Downloads a file from a remote server to the local machine.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| remotePath | Yes | ||
| localPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose behavioral traits such as whether existing files are overwritten, permissions required, or return status. Only the basic action is stated.
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 sentence, but it is under-specified. It is not earning its place—it merely restates the tool's name. True conciseness would front-load critical details without sacrificing essential information.
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 annotations, output schema, and parameter descriptions, the description is completely inadequate. It omits important context about side effects, error conditions, return values, and required preconditions (e.g., connection state), severely hindering correct invocation.
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 0%, and the description adds no meaning beyond parameter names. It does not explain what each parameter (connectionId, remotePath, localPath) represents or how they are used, leaving the agent with no semantic guidance.
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 (Downloads), the resource (file), and the direction (from remote to local). It effectively distinguishes from sibling tools like uploadFile (reverse) and batchDownloadFiles (multiple files).
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., batchDownloadFiles for multiple files), nor any prerequisites like an active connection. The agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a command on a remote server via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| command | Yes | ||
| cwd | No | ||
| timeout | No | ||
| force | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits such as whether the command runs synchronously, its output handling, and potential side effects. The description only states 'executes a command' without any additional behavioral context, making it insufficient.
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 only one sentence, which is under-specified for a tool with five parameters and no annotations. While concise, it fails to provide necessary details, indicating under-specification rather than efficiency.
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 complexity (5 parameters, no annotations, no output schema), the description lacks guidance on return values, side effects, prerequisites (e.g., connection must be active), and error conditions. It is wholly incomplete for reliable tool usage.
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 0%, meaning the description must clarify parameter meanings. The description does not mention any of the five parameters (connectionId, command, cwd, timeout, force), leaving the agent to infer solely from parameter names. This adds no value 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 action 'Executes a command on a remote server via SSH.' It identifies the verb (execute) and resource (command on remote server). However, it does not differentiate from the sibling tool 'backgroundExecute' which likely performs a similar action in the background. Thus, it is clear but not distinguishing.
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 executing remote commands but offers no context on when to use this tool versus alternatives like backgroundExecute or prerequisites such as establishing a connection. It is only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets detailed information about a specific SSH connection.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, required connection state, or return format. The description carries the full burden but adds minimal behavioral context beyond the 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?
The description is a single sentence with no unnecessary words. It is appropriately concise for a straightforward getter, though it could benefit from more detail without harming 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?
Given the lack of output schema and no behavioral annotations, the description is incomplete. It does not specify what 'detailed information' entails or any conditions for use, making it minimally sufficient but requiring the agent to infer 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?
The only parameter, connectionId, has no description in the schema (0% coverage) and the tool description does not explain its meaning or format. The description fails to compensate for the missing schema documentation.
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 gets detailed information about a specific SSH connection, with a clear verb and resource. It distinguishes itself from sibling tools like listConnections by focusing on a single connection.
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. The usage is implied from the name and description, but no differentiation from listConnections or other query tools is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the current working directory of an SSH connection.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behaviors. It only states the action but does not mention side effects, prerequisites (e.g., active connection), error handling, or that it is a read-only operation.
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 with no unnecessary words. It is front-loaded and 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?
Given the simplicity (one parameter, no output schema), the description is minimally adequate. However, it lacks details on prerequisites and return format, which are important for an agent to correctly invoke 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 description coverage is 0%, so the description should compensate. It implies that 'connectionId' identifies an SSH connection but does not explain how to obtain it, its format, or its role beyond being an identifier.
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 'Gets' and the resource 'current working directory of an SSH connection.' It is specific and distinguishes this tool from siblings like 'executeCommand' or 'connect' which perform different actions.
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 is provided on when to use this tool versus alternatives. For example, it does not mention that it should be used before executing commands that depend on the working directory, nor does it 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.
Gets the status of a specific file transfer.
| Name | Required | Description | Default |
|---|---|---|---|
| transferId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Gets the status' implying read-only, but does not disclose behavior on invalid transferId, return format, or side effects.
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?
A single sentence that is concise and front-loaded. Every word 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?
While the tool is simple, the description lacks details on return values, error handling, and relationship to other transfer tools. It is minimally complete but not rich enough for full autonomy.
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 0%. The description uses 'a specific file transfer' to imply the parameter identifies it, but does not explicitly explain what transferId is or its format.
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 'Gets' and resource 'status of a specific file transfer'. It distinguishes from sibling 'listFileTransfers' which lists all transfers.
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 like listFileTransfers. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all currently active SSH sessions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'lists,' implying read-only, but doesn't disclose any behavioral traits like authentication needs or whether the list is real-time or cached.
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 that is direct and efficient. No unnecessary 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?
For a simple list with no parameters and no output schema, the description is largely complete. However, it could mention scope (e.g., sessions for the current user or server) or any limitations.
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?
Input schema has zero parameters with 100% coverage. Baseline is 3 since description adds no additional parameter information, but this is acceptable for a parameterless tool.
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-resource pair: 'Lists all currently active SSH sessions.' It clearly distinguishes from sibling tools like listConnections and listTunnels by focusing on active sessions.
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 such as listConnections or listTunnels. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all background tasks currently running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the tool lists tasks, but fails to disclose important behavioral traits such as whether completed tasks are included, if authentication is required, or the output format. This leaves significant gaps for an agent.
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, front-loaded sentence with no unnecessary words. It efficiently communicates the core functionality.
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 list tool with no parameters and no output schema, the description is adequate but could be improved by providing more context on what information is returned, such as status or IDs. It lacks completeness regarding the output.
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 tool has zero parameters, so baseline 4 applies. The description does not need to add parameter meaning beyond the empty schema, and it succinctly conveys the purpose.
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 lists all currently running background tasks. It uses a specific verb (lists) and resource (background tasks), and differentiates from sibling tools like stopBackground and backgroundExecute.
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 when you need to see background tasks, but provides no explicit guidance on when to use this tool versus alternatives like listActiveSessions or listConnections. No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all saved SSH connections.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral transparency burden. It only states the action without noting any side effects, permissions, or read-only nature. For a list operation, the lack of explicit safety guarantees is a 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?
A single, efficient sentence with no filler. Every word contributes to clarity.
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 list tool with no parameters, the description is adequate but vague. Without an output schema, the agent knows it returns connections but not what fields each connection contains. Additional context about the list's content would improve completeness.
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 tool has zero parameters, so the baseline is 4 per instructions. The description does not add parameter info but is not needed; the schema already covers the trivial case.
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 explicitly states the verb 'Lists' and the resource 'saved SSH connections', making the tool's purpose clear. It differentiates from sibling tools like getConnection (which retrieves a single connection) by implying a full list.
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 usage guidance or alternation with sibling tools is provided. The description is minimal, leaving the agent to infer that this tool is used to view all saved connections, but it does not specify when to use this over getConnection or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all recent file transfers.
| 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 must convey behavioral traits. It only says 'recent file transfers' without defining 'recent', any ordering, limits, or whether the operation is safe. Transparency is minimal; the agent knows it lists transfers but not the details of the behavior.
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 is front-loaded with the action. No extraneous words, and it is appropriately sized for a tool with no parameters.
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 absence of parameters, output schema, and annotations, the description is sufficient for a basic list operation. However, it lacks definition of 'recent', any hint of return structure, and could be more complete by specifying ordering or limits. It is adequate but has gaps.
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 no parameters, so the schema coverage is 100%. Per guidelines, baseline for 0 parameters is 4. The description does not add meaning beyond the empty schema, but no additional meaning is needed.
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 'lists' and the resource 'file transfers' with scope 'all recent'. It is not a tautology and provides the basic purpose. However, it does not differentiate from sibling tools like getFileTransferStatus or listActiveSessions, which could be mistaken for related functionality.
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 is given on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or comparison with sibling tools. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all active SSH tunnels.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'Lists all active SSH tunnels.' It does not disclose read-only nature, authentication needs, or scope (e.g., user-specific vs. all tunnels).
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 wasted words, front-loaded with important verb and resource.
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?
Adequate for a simple list tool with no parameters and no output schema. However, does not explain what 'active' means or what information is returned, leaving some ambiguity.
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?
No parameters, so schema coverage is 100%. The description adds nothing about parameters, but baseline for zero parameters is 4.
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 ('Lists') and the resource ('all active SSH tunnels'), distinguishing it from sibling tools like 'createTunnel' and 'closeTunnel'.
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 like 'listActiveSessions' or 'listConnections'. No context for prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new interactive terminal session.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| rows | No | ||
| cols | No | ||
| term | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'creates' without disclosing side effects, initialization behavior, or whether it requires prior authentication. Important details like session lifecycle, resource limits, or impact on existing sessions are omitted.
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 efficiently states the core function. It avoids unnecessary elaboration, though it might benefit from slightly more detail without becoming verbose.
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 tool's complexity (4 parameters, no output schema, many sibling tools), the description is insufficiently complete. It does not explain what the function returns, how it relates to connect or executeCommand, or what constitutes a valid interactive session. More context is needed for proper selection and 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?
The input schema provides zero descriptions for any of the four parameters (coverage 0%). The description does not explain the purpose or format of connectionId, rows, cols, or term. The parameter names give some hints, but the description adds no additional meaning beyond the raw 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 'Creates a new interactive terminal session' clearly identifies the action (create) and resource (interactive terminal session). This distinguishes it from sibling tools like executeCommand (non-interactive) and backgroundExecute (background execution). However, it could be more explicit about what 'interactive' means in this context.
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 offers no guidance on when to use this tool versus alternatives such as executeCommand or writeToTerminal. It does not mention prerequisites (e.g., an existing connection via connect) or scenarios where this tool is inappropriate (e.g., for non-interactive commands).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Writes data to an interactive terminal session.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits. It does not state whether the tool is idempotent, requires an active session, or what happens if the session is closed. This is a critical gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this brevity is due to omission rather than conciseness. It fails to provide necessary details about behavior and usage, making it 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?
Given the lack of annotations and output schema, and the complexity of interactive terminal operations, the description is severely incomplete. It omits return values, error handling, and behavioral constraints, leaving the agent with insufficient information.
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 0%, and the description does not explain the parameters beyond the schema. It does not describe that 'sessionId' likely comes from createTerminalSession or that 'data' expects a text string. The description adds no semantic value beyond the parameter names.
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 states the tool writes data to an interactive terminal session, which is clear but vague. It does not specify what kind of data (e.g., text, commands) or differentiate it from similar tools like executeCommand. Sibling context helps, but the description alone lacks specificity.
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. There is no mention of prerequisites (e.g., active session from createTerminalSession) or scenarios where executeCommand might be preferred instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stops all running background tasks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states it stops tasks, with no details on side effects, termination guarantees, or recovery options, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One-sentence description is concise and front-loaded, though slightly sparse. Could benefit from brief context about what stopping entails.
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 no parameters and no output schema, the description is minimally adequate but lacks behavioral details that would help an agent understand the full impact of stopping all tasks.
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?
No parameters exist (schema is empty, 100% coverage), baseline is 4. Description adds no parameter info but is not 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?
Description clearly states verb 'stops' and resource 'all running background tasks', distinguishing from siblings like stopBackground (which likely stops a specific task) and listBackgroundTasks.
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?
Implied usage is to stop all background tasks, but no explicit guidance on when to use this vs stopBackground (specific task) or any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stops a background command execution on a specific connection.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states it stops execution but offers no details about side effects, state changes, or error conditions. The agent cannot infer safety or behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core action. It is front-loaded and to the point, though lacks additional structured details.
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 stop operation with one parameter and no output schema, the description provides the minimally necessary information. However, it omits details about what happens after stopping (e.g., task status, logs) and does not leverage the context of sibling tools.
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 0%, yet the description adds no explicit parameter explanation. It implies 'connectionId' via 'on a specific connection' but does not clarify the parameter's format, role, or constraints.
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 ('Stops') and the resource ('background command execution') scoped to 'a specific connection'. This distinguishes it from the sibling 'stopAllBackgroundTasks' which stops all tasks.
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 lacks guidance on when to use this tool vs alternatives like 'stopAllBackgroundTasks'. No context is provided about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uploads a local file to a remote server.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | ||
| localPath | Yes | ||
| remotePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details such as whether it overwrites existing files, requires specific permissions, or returns transfer status. The description is too sparse to inform an agent about side effects.
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?
A single sentence with no unnecessary words. It is concise and front-loaded.
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 annotations, no output schema, and three undocumented parameters, the description is grossly incomplete. It fails to cover return values, failure modes, overwrite behavior, or any other context needed for an agent to use this tool safely.
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 0%, and the description adds no meaning to the parameters. It does not explain what localPath and remotePath should contain (absolute paths, relative paths, supported schemes) or what connectionId refers to.
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 (uploads) and the resource (local file to remote server). It is specific but does not differentiate from similar tools like batchUploadFiles, though it is distinct enough given the sibling list.
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 like batchUploadFiles or downloadFile. No prerequisites or context provided.
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.0backgroundExecutebatchDownloadFilesbatchUploadFilescloseTunnelconnectcreateTunneldeleteConnectiondisconnectdownloadFileexecuteCommandgetConnectiongetCurrentDirectorygetFileTransferStatuslistActiveSessionslistBackgroundTaskslistConnectionslistFileTransferslistTunnelsmcp_ssh_mcp_createTerminalSessionmcp_ssh_mcp_writeToTerminalstopAllBackgroundTasksstopBackgrounduploadFileTools target distinct operations: connection lifecycle, file transfers (single/batch), background execution, tunnels, and terminal sessions. No two tools have overlapping purposes, making selection unambiguous.
Most tools follow camelCase (e.g., executeCommand, downloadFile), but two terminal tools use snake_case with a prefix (mcp_ssh_mcp_createTerminalSession, mcp_ssh_mcp_writeToTerminal), breaking consistency. This mixed convention reduces predictability.
23 tools cover a broad SSH domain—connections, file transfers (single/batch), background tasks, tunnels, and terminal sessions—without redundant or excessive tools. Each tool serves a clear purpose.
Core SSH workflows (connect, execute, transfer, tunnel, terminal) are well covered. Minor gaps exist, such as no directory listing or file editing commands, but these are non-essential for typical SSH operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shuakami/mcp-ssh'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
