de en es ja ko ru zh

MCP Server for FTP Access

Name: MCP Server for FTP Access
Author: alxspiker

by alxspiker

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Servidor MCP para acceso FTP

Este servidor del Protocolo de Contexto de Modelo (MCP) proporciona herramientas para interactuar con servidores FTP. Permite a Claude.app listar directorios, descargar y subir archivos, crear directorios y eliminar archivos/directorios en servidores FTP.

Características

Listar contenido del directorio: Ver archivos y carpetas en el servidor FTP
Descargar archivos: Recuperar el contenido de archivos desde el servidor FTP
Subir archivos: Crear nuevos archivos o actualizar los existentes
Crear directorios: Crear nuevas carpetas en el servidor FTP
Eliminar archivos/directorios: Eliminar archivos o directorios

Related MCP server: MCP SSH Server

Instalación

Instalación a través de Smithery

Para instalar mcp-server-ftp para Claude Desktop automáticamente a través de Smithery:

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

Requisitos previos

Node.js 16 o superior
Claude for Desktop (u otro cliente compatible con MCP)

Construcción desde el código fuente

Linux/macOS

# Clone the repository
git clone https://github.com/alxspiker/mcp-server-ftp.git
cd mcp-server-ftp

# Install dependencies
npm install

# Build the project
npm run build

Windows

# Clone the repository
git clone https://github.com/alxspiker/mcp-server-ftp.git
cd mcp-server-ftp

# Run the Windows build helper script
build-windows.bat

El script build-windows.bat gestiona la instalación de dependencias y la construcción en sistemas Windows, con opciones de respaldo si el compilador de TypeScript presenta problemas.

Configuración

Para usar este servidor con Claude for Desktop, añádelo a tu archivo de configuración:

MacOS/Linux

Edita ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "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_USER": "your-username",
        "FTP_PASSWORD": "your-password",
        "FTP_SECURE": "false"
      }
    }
  }
}

Windows

Edita %APPDATA%\Claude\claude_desktop_config.json:

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

Solución de problemas de construcción en Windows

Si encuentras problemas de construcción en Windows:

Usa el script build-windows.bat proporcionado, que gestiona los problemas de construcción comunes
Asegúrate de que Node.js y npm estén instalados correctamente
Intenta ejecutar el compilador de TypeScript directamente: npx tsc
Si aún tienes problemas, puedes usar los archivos precompilados en el directorio build ejecutando:
```
node path\to\mcp-server-ftp\build\index.js
```

Opciones de configuración

Variable de entorno	Descripción	Predeterminado
`FTP_HOST`	Nombre de host o dirección IP del servidor FTP	localhost
`FTP_PORT`	Puerto del servidor FTP	21
`FTP_USER`	Nombre de usuario FTP (admite cifrado)	anonymous
`FTP_PASSWORD`	Contraseña FTP (admite cifrado)	(cadena vacía)
`FTP_SECURE`	Usar FTP seguro (FTPS), ignorado cuando `FTP_PROTOCOL=sftp`	false
`FTP_PROTOCOL`	Protocolo a utilizar: `ftp` o `sftp`	ftp
`FTP_PRIVATE_KEY_PATH`	Ruta a la clave privada SSH para SFTP (ej. `~/.ssh/id_ed25519`)	(detección automática)
`FTP_PASSPHRASE`	Frase de contraseña para la clave privada SSH (admite cifrado)	(cadena vacía)
`FTP_ENCRYPTION_KEY`	Clave AES-256 hexadecimal de 64 caracteres para descifrar credenciales	(deshabilitado)

Soporte para SSH / SFTP

Además de FTP y FTPS simples, el servidor admite SFTP (Protocolo de transferencia de archivos SSH), que se ejecuta sobre una conexión SSH cifrada y no está relacionado con FTPS.

Establece FTP_PROTOCOL=sftp para cambiar el servidor al modo SFTP. El puerto predeterminado cambia a 22.

Autenticación

SFTP admite dos métodos de autenticación, elegidos automáticamente:

Clave privada: si se encuentra una clave (ver más abajo), se utiliza para la autenticación. FTP_PASSPHRASE se utiliza para descifrar la clave si está protegida por una frase de contraseña.
Contraseña: si no se encuentra ninguna clave, se utiliza FTP_PASSWORD para la autenticación por contraseña.

Detección de claves

El servidor busca una clave privada en este orden:

La ruta en FTP_PRIVATE_KEY_PATH (si está configurada)
~/.ssh/id_ed25519
~/.ssh/id_rsa
~/.ssh/id_ecdsa

Ejemplo de configuración

{
  "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"
      }
    }
  }
}

FTP_PASSPHRASE y FTP_USER admiten el formato cifrado enc: — ver Cifrado de credenciales.

Cifrado de credenciales

Almacenar contraseñas en texto plano en tu archivo de configuración de Claude es un riesgo de seguridad. El servidor admite el cifrado AES-256-GCM para FTP_USER y FTP_PASSWORD, de modo que la configuración solo contenga texto cifrado.

1. Generar una clave de cifrado

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

Mantén esta clave en secreto; trátala como una contraseña maestra.

2. Cifrar un valor de credencial

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

El resultado es una cadena cifrada autocontenida en el formato enc:<iv_hex>:<tag_hex>:<ciphertext_hex>.

3. Usar los valores cifrados en tu configuración

Establece FTP_ENCRYPTION_KEY junto con las credenciales cifradas. Los valores que no comienzan con enc: se tratan como texto plano, por lo que puedes cifrar de forma selectiva.

{
  "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_USER": "enc:aabbcc...:ddeeff...:112233...",
        "FTP_PASSWORD": "enc:aabbcc...:ddeeff...:112233...",
        "FTP_SECURE": "false",
        "FTP_ENCRYPTION_KEY": "<your-64-char-hex-key>"
      }
    }
  }
}

Uso

Después de configurar y reiniciar Claude for Desktop, puedes usar lenguaje natural para realizar operaciones FTP:

"Lista los archivos en el directorio /public en mi servidor FTP"
"Descarga el archivo /data/report.txt del servidor FTP"
"Sube este texto como un archivo llamado notes.txt al servidor FTP"
"Crea un nuevo directorio llamado 'backups' en el servidor FTP"
"Elimina el archivo obsolete.txt del servidor FTP"
"Elimina el directorio vacío /old-project del servidor FTP"

Herramientas disponibles

Nombre de la herramienta	Descripción
`list-directory`	Listar el contenido de un directorio FTP
`download-file`	Descargar un archivo del servidor FTP
`upload-file`	Subir un archivo al servidor FTP
`create-directory`	Crear un nuevo directorio en el servidor FTP
`delete-file`	Eliminar un archivo del servidor FTP
`delete-directory`	Eliminar un directorio del servidor FTP

Consideraciones de seguridad

Utiliza la función de Cifrado de credenciales para evitar almacenar contraseñas en texto plano en tu archivo de configuración.
Prefiere SFTP (FTP_PROTOCOL=sftp) sobre FTP o FTPS simples siempre que sea posible; utiliza SSH y no requiere gestión de certificados.
Considera usar FTPS (FTP seguro) configurando FTP_SECURE=true si tu servidor lo admite pero SFTP no está disponible.
El servidor crea archivos temporales para subidas y descargas en el directorio temporal de tu sistema.

Licencia

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 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 2 months ago (2026-07-25 07:06 UTC)
9
8 npm
1
MIT

Servidor MCP para acceso FTP

Características

Instalación

Instalación a través de Smithery

Requisitos previos

Construcción desde el código fuente

Linux/macOS

Windows

Configuración

MacOS/Linux

Windows

Solución de problemas de construcción en Windows

Opciones de configuración

Soporte para SSH / SFTP

Autenticación

Detección de claves

Ejemplo de configuración

Cifrado de credenciales

1. Generar una clave de cifrado

2. Cifrar un valor de credencial

3. Usar los valores cifrados en tu configuración

Uso

Herramientas disponibles

Consideraciones de seguridad

Licencia

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