Create a directory on a remote server via SFTP. Specify the server using alias or host; recursively create parent directories with the recursive option.
在远程服务器创建目录。使用 alias（推荐）或 host 指定目标服务器，单连接时可省略。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 目录路径（必需） | |
| alias | No | 服务器别名（推荐） | |
| host | No | 服务器地址（多个活跃连接时必须指定，单连接时可省略） | |
| port | No | SSH 端口（可选） | |
| username | No | 用户名（可选，配合 host 使用） | |
| recursive | No | 是否递归创建父目录（默认 false） | |
| targetConfirmationToken | No | 服务器切换确认 token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action and connection hint, but fails to disclose side effects (e.g., behavior if directory already exists, error handling, or permissions required). No annotation contradiction.
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?
Description is two sentences with no waste, front-loads the main action, and provides essential guidance succinctly.
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 schema covering all parameters, the description lacks explanation of return values, error behavior, and the purpose of the recursive and targetConfirmationToken parameters. For a tool with 7 parameters and no output schema, this is insufficient.
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 100% coverage for all 7 parameters. The description adds useful context about when alias/host are needed, going beyond the schema descriptions. However, it does not elaborate on other parameters like recursive or targetConfirmationToken.
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 '在远程服务器创建目录' (create directory on remote server), providing a specific verb and resource. It distinguishes from sibling tools like sftp_ls, sftp_rm, and sftp_upload, which have different purposes.
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?
Describes when to use alias (recommended) or host to specify the target server, and notes that these can be omitted when there is a single active connection. This provides clear context for usage, though it does not explicitly mention when not to use the tool or point to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jiahuidegit/ssh-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server