What can you do with this server?

This server provides FTP, FTPS, and SFTP file-management tools for MCP clients. * List directories – List contents of a remote directory. * Download files – Download text as-is or binary as base64. * Upload files – Upload text or base64-encoded binary content. * Create directories – Create a new directory. * Delete files – Delete a file. * Delete directories – Delete a directory. * Rename/move – Rename or move a file or directory. * Edit files – Replace exact text in a remote text file. * Append to files – Append content, creating the file if needed.

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 "Deploy 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 Source Related Servers Discussions Admin

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

Tool calls return machine-readable structuredContent, and all nine tools advertise output schemas. Version 1.2.2 includes a compatibility shim that ensures advertised schemas use the JSON Schema 2020-12 dialect required by current MCP clients.

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/5.0

Behavior4/5

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

Annotations declare destructiveHint=false, idempotentHint=false, and readOnlyHint=false, covering the mutation profile. The description adds valuable behavioral context beyond annotations: the file is created if it doesn't exist (not obvious from annotations, which say non-destructive), and the binary encoding option. It doesn't mention permissions or error behavior, but the create-if-missing behavior is a meaningful disclosure.

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 compact sentences with zero waste. The core operation is front-loaded, and the create-if-missing and encoding hints follow immediately. Every clause 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 3-param mutation tool with an output schema (return values need not be explained), the description covers the operation, create-if-missing behavior, and binary encoding. It could mention permissions or max file size but is largely complete for correct invocation.

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% – all three parameters (remotePath, content, encoding) have descriptions and encoding has an enum. The description adds the 'base64 for binary content' hint, which clarifies the enum's purpose beyond the schema's plain 'Encoding of the provided content', but is largely redundant with the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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?

States a specific verb (append) and resource (file on FTP server) and distinguishes itself from siblings like upload-file (overwrites/uploads entire file) and edit-file (in-place modification) by specifying append-to-end semantics. The parenthetical about creating the file adds scope clarity.

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 when to use it (appending rather than overwriting) but does not explicitly compare against siblings like upload-file or edit-file. An agent can infer the distinction from the verb 'append' but no explicit when/when-not guidance is provided.

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

create-directoryCreate DirectoryB

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

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the safety and idempotency profile. The description adds only that the operation targets the FTP server, which is minimal beyond the resource name. No additional behavioral context (e.g., what happens if directory exists, permission requirements) is provided.

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?

A single, efficient sentence with no wasted words. Purpose is front-loaded and immediately clear.

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?

With one parameter, full schema coverage, annotations, and an output schema, the description is adequate but minimal. It lacks any guidance on usage context or edge cases, which could be helpful for an FTP directory creation tool.

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 fully documents the single parameter. The description adds no parameter semantics beyond what the schema provides, making baseline 3 appropriate.

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

Purpose4/5

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

The description states a specific verb (Create) and resource (directory) on the FTP server, making the purpose clear. It does not distinguish itself from siblings like delete-directory or list-directory, but the verb+resource combination 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 when-to-use guidance is provided. The description does not mention prerequisites (e.g., parent directory must exist) or alternatives. An agent must infer usage from the tool name and schema alone.

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

delete-directoryDelete DirectoryC

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

C2.9/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds only the target system and says nothing about empty-directory behavior, recursion, or failure modes for a destructive operation.

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

Conciseness4/5

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

One short sentence, front-loaded with the verb and resource, with no filler. It is efficient, though it is arguably terse enough to leave the tool's important edge cases unexplained.

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?

An output schema exists and annotations carry the destructive/idempotent profile, so return values and safety need not be re-explained. Still, for a destructive filesystem operation on a remote server, the omission of non-empty-directory behavior and irreversibility leaves a meaningful gap.

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 description coverage is 100% and there is a single parameter (remotePath) already documented in the schema, so the baseline of 3 applies. The description adds no path format, relative-vs-absolute, or quoting detail beyond the schema.

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

Purpose4/5

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

States a clear verb (delete) and resource (directory) plus the target system (FTP server). The resource noun implicitly separates it from delete-file, though the description never says so explicitly.

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 versus delete-file, or versus create-directory/rename-file. No mention of prerequisites such as whether the directory must be empty or whether the deletion is recursive.

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.1/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that baseline — no note on irreversibility of the remote file, permission requirements, or behavior when the path does not exist.

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?

One short sentence, verb-first and waste-free. Nothing redundant is included and the scope qualifier is attached directly to the action.

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?

An output schema exists so return values need not be explained, and annotations cover the destructive/idempotent profile. Still, for a destructive remote-FTP operation the definition is thin on failure modes and scope limits, leaving it only minimally 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% with a single documented remotePath parameter, so the schema fully carries parameter meaning. The description adds no format, path-syntax, or directory-vs-file clarification, making the baseline 3 appropriate.

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

Purpose4/5

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

States a specific verb (delete) and resource (file) and scopes it to the FTP server, so an agent can distinguish it from delete-directory and rename-file. It stops short of an explicit contrast with those siblings, which only the resource noun implies.

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 when-to-use guidance, no prerequisites, and no mention of the sibling delete-directory or when to prefer rename/overwrite instead of deletion. The agent is left to infer everything from the name.

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
`encoding`	Yes
`remotePath`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added contribution is the type-dependent encoding behavior: text returned as-is, binary base64-encoded. That is a genuinely useful, non-obvious trait an agent must know to interpret the response. It stops short of mentioning size limits, the text/binary detection heuristic, or failure modes.

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

Conciseness5/5

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

Two compact sentences with zero waste: the action is front-loaded and the encoding caveat follows immediately. Every clause earns its place.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, yet the description still handles the one non-obvious return nuance (base64 for binary). With a single fully documented required parameter and matching annotations, nothing needed to call this correctly is missing.

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 description coverage is 100% and the single remotePath parameter is already documented in the schema, so baseline 3 applies. The description adds no syntax, path-format, or constraint detail beyond what structured data provides.

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

Purpose4/5

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

States a specific verb and resource ('Download a file from the FTP server'), which is unambiguous and clearly distinct in intent from upload-file, list-directory, and delete-file. It does not explicitly name a sibling or draw a boundary, so it falls just short of the top score.

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?

There is no when-to-use or when-not-to-use guidance. It never says what condition should route an agent here versus list-directory or edit-file, nor any prerequisite (e.g., the file must exist or be readable). Only the retrieval semantics are described.

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
`remotePath`	Yes
`replacements`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the mutation/safety profile is covered. The description adds meaningful behavioral context beyond that: it discloses the exact-string replacement mechanism and the critical constraint that oldText must match including whitespace and be unique unless replaceAll is set.

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 filler. The purpose and efficiency benefit are front-loaded, followed by the key constraint, making it easy to scan and act on.

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?

With an output schema present, return values needn't be explained, and annotations cover the safety profile. The description covers the mechanism and the main gotcha (exact match, uniqueness, replaceAll), though it omits failure behavior when oldText is not found or not unique, which would be helpful for a mutation tool.

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 description coverage is 100%, so the schema already documents all four parameters including oldText's exact-match nature and replaceAll's uniqueness-bypass behavior. The description reinforces the exact-match/whitespace requirement, adding marginal emphasis but no new semantic detail 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 names a specific verb (Edit), resource (a text file on the FTP server), and mechanism (replacing an exact string without re-uploading the whole file content). That mechanism implicitly distinguishes it from siblings like upload-file and append-file, so an agent can route correctly without opening schemas.

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 phrase 'without re-uploading the whole file content' implies the tool is for small, targeted edits rather than full-file replacement, which is useful implied guidance. However, it never explicitly states when to choose this over upload-file or append-file, nor does it list prerequisites, so usage remains inferred rather than stated.

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

list-directoryList DirectoryB

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
`entries`	Yes
`fileCount`	Yes
`totalCount`	Yes
`directoryCount`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds no behavioral context beyond what is in the annotations, such as pagination, output format details, or error handling.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple tool.

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?

Given the tool's simplicity (one parameter, read-only) and the presence of an output schema, the description is adequate. However, it could benefit from a brief note on when to use it versus other directory-related tools.

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 description coverage is 100%, so the parameter is fully documented in the schema. The description does not add any meaning beyond what the schema provides.

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

Purpose4/5

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

States a specific verb ('List') and resource ('contents of an FTP directory'). It is clear and distinct from siblings like download-file or delete-directory, though it doesn't explicitly contrast itself with any sibling.

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, nor does it mention any prerequisites or exclusions. It simply states what the tool does.

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

rename-fileRename / MoveB

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

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds only that it operates on directories as well as files and on FTP specifically; it does not disclose what happens if the destination path already exists, which is the key behavioral question for a destructive rename.

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?

A single front-loaded sentence with the operation first and the scope qualifier second. Every word earns its place and there is no filler.

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?

An output schema exists, so return values need not be explained, and annotations carry the mutation/destructive profile. The one meaningful gap is destination-overwrite behavior, which matters for a non-idempotent, destructive move.

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 description coverage is 100% and both fromPath/toPath are documented as current and new paths, so the baseline is 3. The description adds no syntax, path-format, or root-relative guidance beyond the schema.

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

Purpose4/5

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

States a specific verb pair (rename/move) and resource (file or directory) plus the operating context (FTP server). It is distinguishable from siblings like edit-file or upload-file, though it never names an alternative to contrast against.

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 rename/move versus edit-file or create-directory, and no prerequisites or exclusions are stated. The agent must infer usage purely from the tool name and schema.

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

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 idempotentHint=true, so the agent knows this can overwrite and is safe to retry. The description adds the encoding option, but doesn't explain what happens if the file already exists (overwrite? error?), or whether it requires specific permissions. Some added value, but gaps remain.

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 core action and a key parameter tip. 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?

Given the simple parameter set, full schema coverage, and annotations covering safety and idempotency, the description is nearly complete. It could mention overwrite behavior, but that's a minor gap.

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 description coverage is 100%, so the schema fully documents the parameters, including the encoding enum and defaults. The description only repeats the encoding option for binary content, adding no new syntax or format details. Baseline 3 is appropriate.

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

Purpose4/5

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

States a specific verb (upload) and resource (file to the FTP server), which is clear. It doesn't explicitly differentiate from siblings like append-file or edit-file, but the action is distinct enough that an agent can infer its purpose.

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 (use base64 for binary), but does not specify when to use this tool versus append-file or edit-file, nor does it mention prerequisites like authentication or directory existence. No explicit when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv1.2.2Sep 13, 2026

Changedappend-file3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

Changedcreate-directory3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

Changeddelete-directory3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

Changeddelete-file3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

Changeddownload-file5 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

removedOutput schema / properties / content / description

Removed value: -"File content, encoded per the encoding field"

removedOutput schema / properties / encoding / description

Removed value: -"utf8 for text files, base64 for binary files"

Changededit-file5 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

removedOutput schema / properties / fileSize / description

Removed value: -"Size of the file in bytes after the edit"

removedOutput schema / properties / replacements / description
```
Removed value: -"Number of occurrences replaced"
```

Changedlist-directory6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```
removedOutput schema / properties / entries / description
```
Removed value: -"Directory entries"
```
removedOutput schema / properties / entries / items / additionalProperties
```
Removed value: -false
```
removedOutput schema / properties / path / description
```
Removed value: -"The directory that was listed"
```

Changedrename-file3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

Changedupload-file3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -false
```

3 tool updatesv1.2.1Aug 12, 2026
- Addeddelete-directory
- Addedlist-directory
- Addedupload-file

9 tool updatesv1.2.0Jul 26, 2026

Addedappend-file

Changedcreate-directory1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "created": {
+      "type": "boolean"
+    },
+    "remotePath": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "remotePath",
+    "created"
+  ],
+  "type": "object"
+}

Removeddelete-directory

Changeddelete-file1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "deleted": {
+      "type": "boolean"
+    },
+    "remotePath": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "remotePath",
+    "deleted"
+  ],
+  "type": "object"
+}

Changeddownload-file1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "content": {
+      "description": "File content, encoded per the encoding field",
+      "type": "string"
+    },
+    "encoding": {
+      "description": "utf8 for text files, base64 for binary files",
+      "enum": [
+        "utf8",
+        "base64"
+      ],
+      "type": "string"
+    },
+    "remotePath": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "remotePath",
+    "content",
+    "encoding"
+  ],
+  "type": "object"
+}

Addededit-file
Removedlist-directory
Addedrename-file
Removedupload-file

6 tool updatesAug 18, 2025
- First observedcreate-directory
- First observeddelete-directory
- First observeddelete-file
- First observeddownload-file
- First observedlist-directory
- First observedupload-file

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-09-13 01:40 across 9 tools

Disambiguation4/5

Most tools have clearly distinct purposes: listing, downloading, directory creation/deletion, file deletion, and renaming. However, upload-file, append-file, and edit-file all modify file content and could be confused in edge cases, though their descriptions differentiate overwrite-style upload, append, and in-place string editing.

Naming Consistency5/5

All tool names follow a consistent kebab-case verb_noun pattern: list-directory, download-file, upload-file, create-directory, delete-file, delete-directory, rename-file, edit-file, append-file. There are no deviations in casing or verb style.

Tool Count5/5

Nine tools is well-scoped for an FTP access server, covering core file and directory operations without excessive breadth. Each tool earns its place by mapping to a distinct FTP action.

Completeness4/5

The set covers core FTP lifecycle operations: list, download, upload, create, delete, rename, edit, and append, for both files and directories. Minor gaps exist around file metadata/stat inspection and potentially recursive directory deletion, but agents can work around these.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

ShareWatch AOAuth
ai.sharewatch
Give Claude only the Google Drive files you choose. Every action logged.
Cloud Storage File Systems Workplace & Productivity
251
platform7nOAuth
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
Fathom MCP ServerOAuth
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 8 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 3 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 2 months ago (2026-07-25 07:06 UTC)
9
8 npm
1
MIT

MCP Server for FTP, FTPS, and SFTP Access

Protocol support

Features

Installation

Installing via Smithery

Prerequisites

Installing via npm

Building from source

Configuration

FTP example

FTPS example

SFTP example

Configuration options

SFTP authentication

Reading an SFTP key from 1Password

Credential encryption

Generate an encryption key

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

Encrypt a value

Available tools

Security notes

Troubleshooting Windows builds

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches