What can you do with this server?

This MCP Server enables interactions with FTP servers through a Model Context Protocol interface. You can: * List directory contents * Download files * Upload files * Create new directories * Delete files and directories

Which integrations are available for this server?

Allows interaction with FTP servers to list directory contents, download and upload files, create directories, and delete files/directories remotely.

How do I use MCP Server for FTP Access?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server for FTP Access list the files in the /public directory" 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.

de en es ja ko ru zh

MCP Server for FTP Access

by alxspiker

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MCP Server for FTP, FTPS, and SFTP Access

This Model Context Protocol (MCP) server provides file-management tools for FTP, FTPS, and SFTP servers. It supports directory listing, binary-safe downloads/uploads, text edits, appends, renames/moves, directory creation, and deletion.

Protocol support

FTP — traditional FTP, normally on port 21.
FTPS — FTP secured with TLS. Use FTP_PROTOCOL=ftp and FTP_SECURE=true.
SFTP — SSH File Transfer Protocol, normally on port 22. SFTP is a different protocol from FTPS and is already encrypted by SSH, so FTP_SECURE does not apply to it.

Related MCP server: MCP SSH Server

Features

List files and directories
Download and upload text or binary files
Edit exact text in remote files
Append to files
Rename or move files/directories
Create and delete directories
FTP, FTPS, and SFTP support
SFTP password or SSH private-key authentication
Optional 1Password CLI private-key resolution
AES-256-GCM encrypted credential values
OS-keychain support for the encryption key

Installation

Installing via Smithery

npx -y @smithery/cli install alxspikers-team/mcp-server-ftp --client claude

Prerequisites

Node.js 18.14 or newer
An MCP-compatible client such as Claude Desktop

Installing via npm

The server is published as mcp-server-ftp:

{
  "mcpServers": {
    "ftp-server": {
      "command": "npx",
      "args": ["-y", "mcp-server-ftp"],
      "env": {
        "FTP_HOST": "ftp.example.com"
      }
    }
  }
}

Building from source

git clone https://github.com/alxspiker/mcp-server-ftp.git
cd mcp-server-ftp
npm install
npm run build

Configuration

FTP example

{
  "mcpServers": {
    "ftp-server": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-server-ftp/build/index.js"],
      "env": {
        "FTP_HOST": "ftp.example.com",
        "FTP_PORT": "21",
        "FTP_PROTOCOL": "ftp",
        "FTP_USER": "your-username",
        "FTP_PASSWORD": "your-password"
      }
    }
  }
}

FTPS example

FTPS uses the normal FTP client with TLS enabled:

{
  "mcpServers": {
    "ftp-server": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-server-ftp/build/index.js"],
      "env": {
        "FTP_HOST": "ftps.example.com",
        "FTP_PORT": "21",
        "FTP_PROTOCOL": "ftp",
        "FTP_SECURE": "true",
        "FTP_USER": "your-username",
        "FTP_PASSWORD": "your-password"
      }
    }
  }
}

FTP_SECURE is only meaningful when FTP_PROTOCOL=ftp. It is ignored by the SFTP path because SFTP is already encrypted over SSH.

SFTP example

{
  "mcpServers": {
    "ftp-server": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-server-ftp/build/index.js"],
      "env": {
        "FTP_HOST": "sftp.example.com",
        "FTP_PORT": "22",
        "FTP_PROTOCOL": "sftp",
        "FTP_USER": "your-username",
        "FTP_PRIVATE_KEY_PATH": "~/.ssh/id_ed25519",
        "FTP_PASSPHRASE": "your-key-passphrase"
      }
    }
  }
}

Configuration options

Environment variable	Applies to	Description	Default
`FTP_HOST`	all	Server hostname or IP address	`localhost`
`FTP_PORT`	all	Server port	`21` for FTP/FTPS, `22` for SFTP
`FTP_PROTOCOL`	all	`ftp` or `sftp`	`ftp`
`FTP_USER`	all	Username; supports encrypted `enc:` values	`anonymous`
`FTP_PASSWORD`	all	Password; supports encrypted `enc:` values	empty
`FTP_SECURE`	FTP/FTPS only	Enables TLS/FTPS for the FTP client	`false`
`FTP_PRIVATE_KEY_PATH`	SFTP only	SSH private-key path or `op://` 1Password secret reference	auto-detect
`FTP_PASSPHRASE`	SFTP only	SSH private-key passphrase; supports encrypted `enc:` values	empty
`FTP_ENCRYPTION_KEY`	encrypted credentials	64-character hex AES-256 key. Prefer the OS keychain or a global environment variable for local installs.	disabled

SFTP authentication

SFTP supports private-key and password authentication.

The server looks for a private key in this order:

FTP_PRIVATE_KEY_PATH, if set
~/.ssh/id_ed25519
~/.ssh/id_rsa
~/.ssh/id_ecdsa

If no key is found, FTP_PASSWORD is used.

Reading an SFTP key from 1Password

FTP_PRIVATE_KEY_PATH may contain a 1Password secret reference instead of a filesystem path:

"FTP_PRIVATE_KEY_PATH": "op://Private/my-server/private key"

Requirements:

The 1Password CLI (op) must be installed and available on PATH.
The CLI must already be able to authenticate, either through the desktop-app integration or OP_SERVICE_ACCOUNT_TOKEN.

The key is resolved lazily, cached in memory for the process, and is not written to disk.

If the SSH server rejects 1Password's default exported key format, request OpenSSH format:

"FTP_PRIVATE_KEY_PATH": "op://Private/my-server/private key?ssh-format=openssh"

Credential encryption

FTP_USER, FTP_PASSWORD, and FTP_PASSPHRASE may be stored as AES-256-GCM encrypted values using the enc: format.

Generate an encryption key

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Store the key in the OS keychain (recommended for local installs)

npm run build
npm run store-key -- <your-64-char-hex-key>

The server loads the key from macOS Keychain, Windows Credential Manager, or Linux Secret Service when available.

Alternatively, set the key globally in the process environment:

export FTP_ENCRYPTION_KEY=<your-64-char-hex-key>

Do not place FTP_ENCRYPTION_KEY beside the encrypted credentials in the same local MCP config unless your deployment environment gives you no separate secret-storage mechanism.

Encrypt a value

npm run build
FTP_ENCRYPTION_KEY=<your-64-char-hex-key> npm run encrypt-env -- <plaintext-value>

If the key is already available from the OS keychain or shell environment:

npm run encrypt-env -- <plaintext-value>

Available tools

Tool	Description
`list-directory`	List contents of a remote directory
`download-file`	Download a file; binary content is returned as base64
`upload-file`	Upload text or base64-encoded binary content
`create-directory`	Create a directory
`delete-file`	Delete a file
`delete-directory`	Delete a directory
`rename-file`	Rename or move a file or directory
`edit-file`	Replace exact text in a remote text file
`append-file`	Append content to a file, creating it if needed

Security notes

Prefer SFTP when available; it uses SSH encryption and key authentication without FTPS certificate configuration.
Use FTP_SECURE=true only for FTPS servers using the FTP protocol path.
Use credential encryption when a client configuration would otherwise contain plaintext credentials.
FTP and SFTP transfers may use short-lived local temporary files for upload/download/append operations; those files are removed during cleanup after each operation.

Troubleshooting Windows builds

Confirm Node.js 18.14 or newer and npm are installed.
Run npm install.
Run npm run build or npx tsc.
Start the compiled server with node build/index.js.

License

MIT

Available Tools

9 tools

append-fileAppend to FileA

Append content to the end of a file on the FTP server (creates the file if it does not exist). Pass encoding "base64" for binary content.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Content to append to the file
`encoding`	No	Encoding of the provided content (default: utf8)
`remotePath`	Yes	Path of the file on the FTP server

Output Schema

ParametersJSON Schema

Name	Required	Description
`remotePath`	Yes
`appendedBytes`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-destructive behavior. The description adds that the file is created if missing and mentions encoding handling. This is adequate for a simple tool, though it could mention concurrency or limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no unnecessary words. Key information is front-loaded and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers core behavior and a notable option (encoding). Given the existence of an output schema and the tool's simplicity, it is complete enough. Minor omission: no mention of error cases or prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters with descriptions. The description adds value by explaining the purpose of encoding ('base64' for binary), which the schema only lists as an enum without usage context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (append content) and the resource (file on FTP server), and uniquely distinguishes itself from siblings like edit-file by noting it appends rather than modifies in-place.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use (appending) and a specific tip for binary content. However, it does not explicitly contrast with sibling tools like edit-file or download-file, leaving some implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-directoryCreate DirectoryA

Idempotent

Create a new directory on the FTP server

ParametersJSON Schema

Name	Required	Description	Default
`remotePath`	Yes	Path of the directory to create

Output Schema

ParametersJSON Schema

Name	Required	Description
`created`	Yes
`remotePath`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide idempotentHint=true and destructiveHint=false, so the safety profile is clear. The description adds 'Create a new directory', which is consistent but does not elaborate on error handling or side effects beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and contains no filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description is adequate but lacks mention of return values, error behavior, or usage context. It does not hinder use but is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the parameter. The description adds no additional meaning or format details for 'remotePath' beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create'), resource ('directory'), and location ('FTP server'). It distinguishes from sibling tools, which are file operations, so the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The sibling tools are file-related, but the description does not mention prerequisites, constraints, or 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.

delete-directoryDelete DirectoryA

DestructiveIdempotent

Delete a directory from the FTP server

ParametersJSON Schema

Name	Required	Description	Default
`remotePath`	Yes	Path of the directory to delete

Output Schema

ParametersJSON Schema

Name	Required	Description
`deleted`	Yes
`remotePath`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare destructiveHint=true and idempotentHint=true, but the description adds no behavioral details beyond the fact that it deletes a directory. It does not mention recursive deletion, error behavior, or prerequisites, so it provides little beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, immediately states the action and target, and contains no unnecessary words. It is perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete operation with annotations and schema coverage, the description is adequate but lacks important operational details like recursive deletion and error handling. The presence of an output schema somewhat compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides a full description for remotePath with 100% coverage, so the description need not explain parameters. It does not add any additional semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Delete' and resource 'directory' with location 'FTP server', clearly distinguishing it from sibling tools like delete-file. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for deleting directories (as opposed to files via delete-file), but it does not explicitly state when to use it or mention alternatives. Usage context is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-fileDelete FileB

DestructiveIdempotent

Delete a file from the FTP server

ParametersJSON Schema

Name	Required	Description	Default
`remotePath`	Yes	Path of the file to delete

Output Schema

ParametersJSON Schema

Name	Required	Description
`deleted`	Yes
`remotePath`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds minimal behavioral insight. It does not mention if deletion is permanent, recursive, or whether it fails on missing file.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 8 words with no fluff. Perfectly concise for a straightforward delete operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 1-parameter, destructive, idempotent tool with an output schema, the description is adequate. It misses optional details like success message or error handling, but the complexity is low.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description 'Path of the file to delete' is clear. The tool description adds no further semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a file from the FTP server', which is a specific verb and resource. It is easily distinguished from sibling tools like append-file, rename-file, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., rename-file or edit-file). The description does not mention prerequisites, exclusions, or context about disk cleanup or refs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download-fileDownload FileA

Read-only

Download a file from the FTP server. Text files are returned as-is; binary files are returned base64-encoded.

ParametersJSON Schema

Name	Required	Description	Default
`remotePath`	Yes	Path of the file on the FTP server

Output Schema

ParametersJSON Schema

Name	Required	Description
`content`	Yes	File content, encoded per the encoding field
`encoding`	Yes	utf8 for text files, base64 for binary files
`remotePath`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, aligning with download. Description adds encoding behavior (as-is for text, base64 for binary), providing useful behavioral detail beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second adds key behavioral detail. No wasted words, front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple file download with one parameter and output schema, description covers purpose and encoding behavior. Could mention error conditions but current is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has one parameter with description 'Path of the file on the FTP server'. Description does not add further meaning. Schema coverage is 100%, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Download a file from the FTP server' – specific verb and resource. Distinguished from siblings like append-file, delete-file, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies retrieval use case, but no explicit when-to-use or when-not-to-use guidance. Sibling names provide context but description itself lacks usage directions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edit-fileEdit FileA

Destructive

Edit a text file on the FTP server by replacing an exact string, without re-uploading the whole file content. oldText must match exactly (including whitespace) and be unique in the file unless replaceAll is set.

ParametersJSON Schema

Name	Required	Description
`newText`	Yes	Text to replace it with
`oldText`	Yes	Exact text to find in the file
`remotePath`	Yes	Path of the file on the FTP server
`replaceAll`	No	Replace every occurrence instead of requiring oldText to be unique (default: false)

Output Schema

ParametersJSON Schema

Name	Required	Description
`fileSize`	Yes	Size of the file in bytes after the edit
`remotePath`	Yes
`replacements`	Yes	Number of occurrences replaced

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (destructiveHint=true), the description adds critical behavioral constraints: oldText must match exactly including whitespace, must be unique in the file unless replaceAll is set. This provides the agent with necessary operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that cover the action, the benefit (no re-upload), and the critical constraint. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential usage and constraints; with an output schema present, return value details are unnecessary. However, it does not mention error scenarios like multiple matches without replaceAll or missing oldText, which might be useful for robustness. Overall, it is sufficiently complete for the agent's decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the input schema already describes all four parameters with 100% coverage, the description adds contextual meaning: it explains that oldText must be unique unless replaceAll is set, and defines replaceAll's purpose in the context of uniqueness. This goes beyond the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Edit', the resource 'text file on FTP server', and the mechanism: string replacement without re-upload. It distinguishes from siblings such as 'append-file' and 'delete-file' by specifying the exact string replacement approach.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when making a targeted string replacement without re-uploading the entire file, but it does not explicitly state when not to use this tool or compare it to alternatives like 'append-file' or download-and-edit workflows. No explicit usage guidance beyond the use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-directoryList DirectoryA

Read-only

List contents of an FTP directory

ParametersJSON Schema

Name	Required	Description	Default
`remotePath`	Yes	Path of the directory on the FTP server

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The directory that was listed
`entries`	Yes	Directory entries
`fileCount`	Yes
`totalCount`	Yes
`directoryCount`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description adds minimal extra context by specifying the FTP scope. It does not mention error behavior, response format, or any edge cases, but given the safety profile is covered, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the essential action and object. No wasted words or redundant phrasing; it earns its place effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with one parameter, a clear purpose, and read-only annotations, the description is sufficiently complete. It doesn't specify recursion or sorting, but these are likely not essential given the presence of an output schema and the straightforward nature of the operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter remotePath is fully described in the schema ('Path of the directory on the FTP server'), achieving 100% schema coverage. The description adds no additional parameter detail, but the baseline of 3 is appropriate when structured data is already informative.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('List') and resource ('contents of an FTP directory'), fully distinguishing it from sibling tools like download-file or delete-file. The wording is unambiguous and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided about when to use this tool versus alternatives, nor are there any exclusions or preferred use cases. The description simply states the action without explaining context, such as 'use to browse directory structure' or 'for file retrieval use download-file'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rename-fileRename / MoveA

Destructive

Rename or move a file or directory on the FTP server

ParametersJSON Schema

Name	Required	Description	Default
`toPath`	Yes	New path for the file or directory
`fromPath`	Yes	Current path of the file or directory

Output Schema

ParametersJSON Schema

Name	Required	Description
`toPath`	Yes
`renamed`	Yes
`fromPath`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's statement 'Rename or move' is consistent but adds no new behavioral details beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that effectively communicates the purpose with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with full schema descriptions and annotations, the description is nearly sufficient. It could mention overwrite behavior or limitations, but given the output schema exists, it is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have descriptions in the schema (100% coverage), and the description does not add extra meaning beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool renames or moves a file or directory on an FTP server. It uses specific verbs (rename, move) and resources (file/directory), distinguishing it from siblings like delete-file or create-directory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention caveats like not for cross-server moves or when not to use it, leaving the agent without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

upload-fileUpload FileA

DestructiveIdempotent

Upload a file to the FTP server. Pass encoding "base64" to upload binary content.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Content to upload to the file
`encoding`	No	Encoding of the provided content (default: utf8)
`remotePath`	Yes	Destination path on the FTP server

Output Schema

ParametersJSON Schema

Name	Required	Description
`remotePath`	Yes
`bytesWritten`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, and the description does not contradict these. It adds no additional behavioral context such as overwrite behavior or required permissions, but the annotations cover the core safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and resource, with a focused note on binary encoding. There is no redundant wording and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter tool with full schema coverage, a defined output schema, and annotations indicating idempotent/destructive behavior, the description covers the primary scenario. It could mention overwrite behavior or directory creation, but this is a minor gap given the structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema documents all three parameters with descriptions, so the description does not need to restate them. The line 'Pass encoding "base64" to upload binary content' adds pragmatic semantics to the encoding parameter beyond its enum definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Upload' and identifies the resource as 'file to the FTP server,' clearly distinguishing it from sibling tools like download-file, edit-file, and append-file. It also adds a relevant detail about base64 encoding for binary content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly compare against sibling tools or state exclusions, but the action 'upload' implies its use for putting files on the FTP server. The guidance to 'Pass encoding base64' gives a concrete condition for binary content, providing some usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct FTP operation: listing, downloading, uploading, directory creation, deletion of files/directories, renaming, and two distinct file modification strategies (edit replacing a string, append adding to end). No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern in kebab-case (e.g., list-directory, download-file, delete-file). The naming is uniform and predictable.

Tool Count5/5

With 9 tools covering file and directory operations, the count is well-scoped for an FTP server MCP. Each tool serves a needed purpose without unnecessary redundancy.

Completeness5/5

The toolset provides comprehensive coverage of FTP file management: list, create, read, write, append, edit, rename/move, and delete for both files and directories. No obvious missing operations for the stated domain.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

ShareWatch
ai.sharewatch
Give Claude only the Google Drive files you choose. Every action logged.
Cloud Storage File Systems Workplace & Productivity
1
platform7n
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
Fathom MCP Server
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216
PDFHaul MCP
com.pdfhaul.www
PDF tools for Claude: merge, split, compress, convert, OCR & more. Requires a PDFHaul API key.
File Systems Workplace & Productivity
2

Related MCP Servers

SSH Remote MCP Server
Shell Access Command Line OS Automation
nqmn
A
license
A
quality
C
maintenance
Enables SSH remote access to servers through Claude, allowing users to execute commands, transfer files via SFTP, and manage multiple remote connections using natural language.
Updated 2 months ago (2026-07-02 23:17 UTC)
12
8
MIT
MCP SSH Server
Shell Access Command Line File Systems
MaraBank
A
license
Not graded
quality
Not graded
maintenance
Connects Claude to remote servers via SSH to execute commands, manage files, and browse directories. It allows users to add, edit, and switch between multiple server configurations through natural language conversations.
Updated 7 months ago (2026-01-19 18:33 UTC)
FS-MCP
File Systems Shell Access Workplace & Productivity
chayan-1906
A
license
Not graded
quality
B
maintenance
Provides Claude with complete file system integration including directory management, file operations, Office document creation/editing, and advanced file tree visualization.
Updated 2 months ago (2026-06-30 18:48 UTC)
3
MIT
claude-ssh-mcp
Shell Access File Systems Command Line
MaraBank
A
license
A
quality
C
maintenance
Enables Claude to connect to servers via SSH, execute commands, transfer files, and manage connections through natural language.
Updated a month ago (2026-07-25 07:06 UTC)
9
16
1
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alxspiker/mcp-server-ftp'

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