ftp-deploy-mcp
ftp-deploy-mcp
El botón de implementación para agentes de codificación de IA. Claude Code · Claude Desktop · Cursor · Windsurf · Trae · Antigravity → tus propios servidores FTP / FTPS / SFTP.
Versión francesa → README.fr.md
Tu agente ejecuta el despliegue: tú solo pides.
Por qué
Todo proyecto web termina igual: "ahora súbelo al servidor".
Los agentes de IA escriben buen código, pero la mayoría no tiene una forma segura de publicarlo en un alojamiento clásico: OVH, Ionos, Hostinger, o2switch y el resto del mundo del alojamiento compartido siguen funcionando con FTP/SFTP, no con
git push.ftp-deploy-mcpofrece a cualquier cliente MCP una vía de despliegue hacia tu propia infraestructura, en la misma conversación donde se escribió el código.A diferencia de los servidores MCP genéricos de ejecución SSH, este está diseñado específicamente para el despliegue de archivos: un aislamiento de ruta (path jail), un modo de solo lectura, simulación (dry-run) y credenciales que nunca entran en el contexto del modelo.
Related MCP server: SSH MCP Server
Características
Característica | Descripción |
Multiservidor | FTP / FTPS / SFTP, cualquier número de servidores en una sola configuración |
Despliegue con un comando | Despliegue recursivo de directorios, exclusiones tipo gitignore a cualquier profundidad, simulación (dry-run) |
Aislamiento de ruta (path jail) | Cada operación confinada bajo una |
Modo de solo lectura | Bloquea cualquier escritura en servidores que deben permanecer intactos |
Importación de FileZilla | Convierte tus sitios existentes de |
Configuración automática | Configura más de 5 clientes MCP automáticamente, con copias de seguridad de configuración con marca de tiempo |
Diagnóstico (Doctor) | Diagnóstico de solo lectura de Node, configuración, servidores y conexiones de clientes |
Cero compilación | JavaScript ESM simple: Node stdlib + 5 dependencias pequeñas |
Seguro por defecto | FTP simple / TLS no verificado rechazado a menos que se permita explícitamente por servidor |
Probado en batalla | 209 aserciones e2e contra servidores FTP + SFTP locales reales |
Sin telemetría | Nada sale de tu máquina excepto las llamadas a tus propios servidores |
Inicio rápido
git clone https://github.com/alebgl77/ftp-deploy-mcp.git && cd ftp-deploy-mcpEjecuta
install.cmd(doble clic, Windows) o./install.sh(macOS / Linux).Reinicia tu IDE y pide a tu agente: "Despliega ./dist a producción".
Cómo funciona
flowchart LR
subgraph agents [AI agents]
A[Claude Code]; B[Cursor]; C[Windsurf]; D[Trae]; E[Antigravity]
end
agents -- MCP stdio --> S[ftp-deploy-mcp<br/>10 tools · path jail · read-only guard]
S -- FTP / FTPS --> F[(your web hosts)]
S -- SFTP --> G[(your servers)]
K[ftp-servers.json<br/>credentials stay local] -.-> S1. Qué es
Un servidor MCP (Model Context Protocol) que se ejecuta sobre stdio y expone 10 herramientas a tu agente de codificación. Las credenciales viven en un archivo de configuración local y nunca viajan a través del contexto del LLM. Cada operación remota está confinada bajo una root que eliges por servidor.
Requiere Node.js >= 18. Sin dependencias nativas que compilar.
2. Instalación
⚡ Instalación con un comando (recomendado)
git clone https://github.com/alebgl77/ftp-deploy-mcp.git
cd ftp-deploy-mcpLuego inicia el asistente:
Windows: haz doble clic en
install.cmd.macOS / Linux:
./install.sh(ejecutachmod +x install.shprimero si es necesario).O manualmente:
npm install && npm run setup.
El asistente setup lo hace todo por ti:
crea o importa tu configuración de servidores (incluida una importación de FileZilla de tus sitios existentes);
prueba la conexión a cada servidor;
escribe automáticamente los archivos de configuración de los clientes MCP detectados (Claude Code, Claude Desktop, Cursor, Windsurf, Antigravity), con una copia de seguridad
.backup-<fecha>antes de modificar cualquier archivo existente;imprime (y copia) un bloque listo para pegar para Trae, que se configura desde su interfaz.
Luego reinicia tu IDE y pide a tu agente, p. ej., "Lista mis servidores FTP".
Diagnóstico y opciones
En cualquier momento, un diagnóstico de solo lectura (no escribe nada):
npm run doctor # or: node src/index.js doctorImprime la versión de Node, qué archivo de configuración está en uso, la lista de servidores (nunca las contraseñas) y, por cliente, si la entrada ftp está conectada a esta instalación.
Opciones de setup (node src/index.js setup [opciones]):
Opción | Efecto |
| No interactivo (conserva la configuración existente o importa con |
| Clientes a configurar (por defecto: todos los detectados). |
| Importar desde FileZilla (ruta opcional → ubicación por defecto). |
| Destino del archivo de configuración (por defecto |
| Omitir las pruebas de conexión. |
| Imprimir las acciones planificadas y no escribir nada. |
| Reemplazar una entrada |
(b) Instalación global
npm install -g .El comando ftp-deploy-mcp ahora está en tu PATH; úsalo en lugar de node .../src/index.js.
(c) Publicar en npm (para uso con npx -y)
Si publicas este paquete en npm bajo tu propio nombre, los clientes pueden ejecutarlo sin instalación previa:
{ "command": "npx", "args": ["-y", "your-package-name"] }3. Configuración del servidor
Crea un archivo ftp-servers.json. El servidor lo busca en este orden (el primero que encuentre gana):
--config <ruta>(bandera de línea de comandos)variable de entorno
FTP_MCP_CONFIG(ruta al JSON)./ftp-servers.json(directorio de trabajo del proceso)~/.ftp-mcp/servers.json
Esquema completo
{
"defaultServer": "prod", // optional: used when "server" is not given
"servers": {
"prod": {
"protocol": "sftp", // REQUIRED: "ftp" | "ftps" | "sftp"
"host": "ssh.example.com", // REQUIRED
"port": 22, // optional (defaults: ftp/ftps 21, implicit ftps 990, sftp 22)
"user": "deploy", // REQUIRED
"password": "${ENV:PROD_PW}", // optional: password (or an env placeholder)
"privateKeyPath": "~/.ssh/id_ed25519", // optional (sftp); "~" is expanded
"passphrase": "…", // optional: private-key passphrase
"root": "/var/www/site", // optional (default "/"): ALL ops are jailed under it
"readOnly": false, // optional: blocks upload/deploy/mkdir/rename/delete
"insecureTLS": false, // optional (ftps): skip certificate checks — requires "allowInsecure"
"implicitTLS": false, // optional (ftps): implicit TLS (port 990, legacy servers)
"allowInsecure": false // optional: explicit opt-in REQUIRED for plain "ftp" or "insecureTLS"
}
}
}El bloque anterior usa comentarios
//solo con fines didácticos. El archivo real debe ser JSON estricto (sin comentarios). Consultaftp-servers.example.json.
Sustitución de variables de entorno
Cualquier valor de cadena puede contener ${ENV:VARIABLE_NAME}. Se reemplaza con el valor de la variable de entorno al inicio. Si la variable no está definida, las herramientas devuelven un error claro que nombra la variable que falta.
"password": "${ENV:OVH_FTP_PASSWORD}"Consejos de seguridad
Prefiere SFTP. El
ftpsimple yftpsconinsecureTLS: truese rechazan por defecto: en esos transportes, un atacante de red puede capturar o alterar credenciales y archivos. Para usarlos de todos modos, debes establecer explícitamente"allowInsecure": trueen ese servidor, y cada registro de inicio y resultado de herramienta llevará una advertencia de seguridad visible.Añade
ftp-servers.jsona tu.gitignore(ya está hecho en este repositorio).Restringe los permisos del archivo (
chmod 600 ftp-servers.jsonen Unix).Prefiere variables de entorno (
${ENV:…}) o una clave SSH en lugar de una contraseña en texto plano.Usa
readOnly: truepara servidores en los que el agente nunca deba escribir.Establece
rootlo más restringida posible: el aislamiento evita cualquier fuga con../.
4. Importar desde FileZilla
¿Ya tienes tus sitios en FileZilla? Conviértelos:
# Auto-detect the default sitemanager.xml location…
node src/index.js import-filezilla
# …or an explicit file, written to an ftp-servers.json
node src/index.js import-filezilla --file /path/sitemanager.xml --out ./ftp-servers.jsonSin --out, el JSON se imprime en stdout. Las contraseñas codificadas en Base64 se decodifican; los sitios sin contraseña almacenada reciben un marcador de posición ${ENV:<NAME>_PASSWORD} (tú mismo estableces la variable). Ejemplo de salida:
{
"defaultServer": "my-site",
"servers": {
"my-site": {
"protocol": "ftp",
"host": "ftp.example.com",
"user": "deploy",
"password": "…",
"root": "/www/html"
}
}
}Aviso: el archivo generado contiene contraseñas en texto plano decodificadas: mantenlo fuera del control de versiones (
.gitignore) y restringe sus permisos (chmod 600).
Sitios FTP simples: los servidores importados con
"protocol": "ftp"(como el ejemplo anterior) se rechazan al conectar hasta que los cambies asftp/ftpso establezcas explícitamente"allowInsecure": trueen ellos; la importación imprime una advertencia para cada uno. Consulta Seguridad.
5. Configuración manual del cliente (si no usas setup)
npm run setupescribe estos archivos automáticamente (con copias de seguridad). Esta sección solo es útil si prefieres configurarlo todo manualmente.
Reemplaza /absolute/path/to/ftp-deploy-mcp/src/index.js con la ruta real (las barras / también funcionan en Windows). Si publicaste el paquete en npm, cambia "command": "node", "args": ["…/src/index.js"] por "command": "npx", "args": ["-y", "your-package-name"].
Las ubicaciones de archivo a continuación son las ubicaciones predeterminadas en el momento de escribir esto; las interfaces de estos productos evolucionan, así que consulta su documentación si es necesario.
Claude Code
.mcp.json en la raíz del proyecto:
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}O en un comando:
claude mcp add ftp -- node /absolute/path/to/ftp-deploy-mcp/src/index.jsClaude Desktop
Windows:
%APPDATA%\Claude\claude_desktop_config.jsonmacOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Cursor
~/.cursor/mcp.json (global) o .cursor/mcp.json (proyecto):
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Windsurf
~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Trae
Trae no tiene un archivo de configuración estable: todo se hace desde su interfaz. Panel de chat de IA → Configuración/engranaje → MCP → Añadir → Configurar manualmente y luego pega (este es el bloque que setup imprime y copia al portapapeles):
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Antigravity
Según la versión, el archivo es uno de:
~/.gemini/antigravity/mcp_config.jsonvariante:
~/.gemini/config/mcp_config.json
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}También puedes usar el panel MCP del agente (gestión de servidores MCP) → añadir un servidor, con la misma estructura.
6. Las 10 herramientas
Todas las rutas remotas (path, remote_path, …) son relativas a la root del servidor y usan estilo POSIX. El parámetro server siempre es opcional (consulta la resolución a continuación).
Tool | Parámetros | Descripción |
| (ninguno) | Lista los servidores configurados (protocolo, host, puerto, raíz, solo lectura, tipo de autenticación). Nunca una contraseña. |
|
| Conecta, lista la raíz, confirma el éxito. |
|
| Lista un directorio remoto (directorios primero). |
|
| Lee un archivo de texto (por defecto 262144, máximo 1048576 bytes). Rechaza archivos binarios. |
|
| Sube un archivo, creando los directorios padre. |
|
| Despliega recursivamente un directorio sobre una única conexión, con exclusiones por defecto. |
|
| Descarga un archivo; se niega a sobrescribir a menos que |
|
| Crea un directorio (recursivo). |
|
| Renombra o mueve. |
|
| Elimina un archivo; un directorio requiere |
Resolución del servidor: parámetro server explícito → defaultServer → el único servidor si solo hay uno → de lo contrario, un error que lista los nombres disponibles.
Exclusiones por defecto de ftp_deploy: **/node_modules/**, **/.git/**, .env, .env.*, *.log, .DS_Store, Thumbs.db, ftp-servers.json, **/.ftp-mcp/** (tus globs de exclude se añaden; include restringe a los archivos que coinciden). Los patrones sin barra coinciden a cualquier profundidad (similar a gitignore): un apps/api/.env anidado también se excluye.
7. Ejemplos de prompts
"Despliega
./disten el servidorprod.""Lista lo que hay en
/wwwenovh.""Obtén el
.htaccessdeprody muéstramelo.""Haz una prueba en seco de desplegar
./builden/wwwpara que pueda ver qué se enviaría.""Renombra
index.old.htmlaindex.htmlenprod."
8. Seguridad
Transportes seguros por defecto: FTP plano y FTPS con verificación de certificado deshabilitada (
insecureTLS: true) son rechazados a menos que la entrada del servidor establezca explícitamente"allowInsecure": true. Cuando se permite, se muestra una advertencia de seguridad al inicio, enftp_list_servers, endoctor, y se añade a cada resultado de herramienta para ese servidor.Raíz restringida: cada operación se normaliza y luego se verifica que permanezca bajo la
rootdel servidor. Cualquier intento de escape (../…) se rechaza, incluso cuandorootes/.Solo lectura:
readOnly: truebloquea toda escritura (subida, despliegue, mkdir, renombrado, eliminación); las lecturas siguen funcionando.Credenciales fuera del LLM: las contraseñas, frases de paso y claves nunca se devuelven en la salida de la herramienta.
Sin telemetría, ninguna conexión saliente aparte de tus propios servidores.
Conexiones por llamada: cada herramienta abre una conexión, realiza la operación y la cierra: no hay sesión persistente.
9. Solución de problemas
Tiempo de espera / no se puede conectar (FTP): normalmente el modo pasivo está bloqueado por un cortafuegos. Asegúrate de que los puertos pasivos de tu servidor sean accesibles.
Autenticación por clave SFTP: establece
privateKeyPath(~se expande) y, si la clave está cifrada,passphrase. Comprueba los permisos de la clave."CONEXIÓN INSEGURA RECHAZADA": el servidor usa FTP plano, o FTPS con verificación de certificado deshabilitada. Cámbialo a
sftp(oftpscon un certificado válido), o — solo si aceptas completamente el riesgo de interceptación — establece"allowInsecure": trueen ese servidor.FTPS autofirmado:
insecureTLS: trueacepta un certificado no verificado. Esto desactiva la protección contra el hombre en el medio, por lo que también requiere"allowInsecure": truee imprime una advertencia de seguridad en cada llamada. Prefiere instalar un certificado válido.FTPS implícito (puerto 990): establece
implicitTLS: true(protocoloftps) para servidores heredados que cifran desde el primer byte, sin un comandoAUTH TLS."no server configured": el archivo no se encontró en ninguna de las 4 ubicaciones. Crea
ftp-servers.jsono pasa--config <ruta>/FTP_MCP_CONFIG=<ruta>.El cliente no ve las herramientas después de
setup: reinicia completamente el IDE (cierra todas las ventanas, no solo el proyecto), luego verifica la conexión connpm run doctor.El servidor se inicia a pesar de una configuración no válida: esto es intencional (a los clientes MCP no les gustan los servidores que mueren al inicio). El error exacto se imprime en
stderral lanzar y se devuelve en cada llamada de herramienta.
Desarrollo
npm test # runs the full smoke test (local FTP + SFTP, no external network)
node src/index.js --version
node src/index.js --helpContribuciones
Las contribuciones son bienvenidas: consulta CONTRIBUTING.md para la configuración de desarrollo, los principios del proyecto y la lista de verificación de PR.
Seguridad
¿Encontraste una vulnerabilidad? Por favor, no abras un issue público: consulta SECURITY.md para saber cómo reportarla de forma privada.
Licencia
MIT — consulta LICENSE.
Available Tools
10 toolsftp_deleteDelete a remote file or directoryADestructiveIdempotent
Delete a remote file, or a directory when recursive:true. Never deletes the server root.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote path to delete, relative to the server root. | |
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. | |
| recursive | No | Required to delete a directory and its contents. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral detail beyond annotations: recursive deletion applies to directories, and the server root is protected. The annotations already signal destructive/idempotent behavior, so the description's extra guardrail and recursive qualification are strong contributions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and the safety constraint immediately after. No filler or repeated schema boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the core behavior, the recursive condition, and a critical root-safety guard. It does not address errors, permissions, or edge cases like nonexistent paths, but for a simple destructive operation with strong annotations and schema coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (all parameters documented). The description adds no new parameter semantics beyond restating that recursive deletion applies to directories, so the schema carries the explanatory burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete'), identifies the target ('remote file' or 'directory'), and includes the recursive condition for directories. This clearly distinguishes it from sibling operations like ftp_read, ftp_upload, and ftp_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when the tool applies (files and directories with recursive=true) and adds a meaningful safety exclusion ('Never deletes the server root'). It does not directly compare with sibling tools, but no sibling covers deletion, so the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_deployDeploy a local directoryADestructive
Recursively upload a local directory to the server over a single connection, applying default and custom exclude globs (and optional include globs). Supports dry_run.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. | |
| dry_run | No | If true, list what would be uploaded without connecting. | |
| exclude | No | Extra glob patterns to exclude, added to the built-in defaults. | |
| include | No | Glob patterns; when given, a file must match at least one to be uploaded. | |
| local_dir | Yes | Local directory to deploy, absolute or relative to the server's configured localRoot. | |
| remote_dir | No | Destination remote directory, relative to the server root. Defaults to the root. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already signal destructiveHint=true and readOnlyHint=false, so the description does not need to prove the operation is a write. It adds useful context about single-connection behavior and dry-run capability, but it does not disclose what the destructive behavior actually affects, such as whether existing remote files are overwritten or whether files absent locally are deleted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences lead with the action and resource, then pack the glob behavior and dry-run support without wasted words. The description is easy to scan and every clause contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete input schema, an output schema, and annotations covering the destructive nature, the description is largely sufficient. The only notable gap is the lack of explicit routing guidance against ftp_upload, but this does not prevent a capable agent from invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all six parameters and the description is not required to compensate. The description reinforces exclude/include semantics and dry_run, but adds little meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('upload'), a specific resource ('local directory'), and the key behavioral qualifiers: recursive traversal, glob-based exclusion/inclusion, single connection, and dry-run support. This separates it from the sibling ftp_upload tool, which appears to target individual files, even though that alternative is not named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: deploy a whole local directory recursively rather than a single file. However, it never explicitly says when to prefer this over ftp_upload or other siblings, nor does it state exclusions such as 'for individual files, use ftp_upload'. The usage context is implied by the wording, but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_downloadDownload a remote fileADestructive
Download a remote file to a local path, auto-creating local parent directories. Refuses to overwrite unless overwrite:true.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. | |
| overwrite | No | Allow overwriting an existing local file. | |
| local_path | Yes | Local destination path, absolute or relative to the server's configured localRoot. | |
| remote_path | Yes | Remote file path, relative to the server root. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses two meaningful behaviors beyond the annotations: it auto-creates local parent directories assuredly, and it refuses to overwrite existing files unless overwrite:true is set. This materially helps the agent anticipate side effects beyond the raw destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences cover the primary action and both edge-case behaviors. No redundancy with the title or the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with a rich input schema and output schema, this is mostly complete. It could mention what happens on remote-file absence or connection failures, but those are minor gaps given the structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameter descriptions (100%), giving a baseline of 3. The description adds relevant semantics by clarifying that local parent directories will be created and that overwrite is disabled by default, which supplements the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('download'), the source ('remote file'), the destination ('local path'), and two behavioral constraints (auto-creating parent directories, refusing to overwrite unless asked). This clearly identifies the tool's job and distinguishes it from siblings like ftp_read or ftp_upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'download a remote file to a local path' gives clear operational context for when this tool would be used. However, it does not explicitly contrast it with alternatives such as ftp_read (view without saving) or mention any selection criteria, so the guidance is mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_listList a remote directoryARead-onlyIdempotent
List the contents of a remote directory (relative to the server root). Directories are listed first.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Remote directory, relative to the server root. Defaults to the root. | |
| limit | No | Maximum entries to return (default 50, maximum 200). | |
| offset | No | Zero-based entry offset (default 0). | |
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds two behavioral facts not in the annotations: directories are listed first, and paths are relative to the server root. This adds value beyond structured metadata without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The primary action and the most important scoping constraint are front-loaded, and the behavioral note about directory ordering is a single clause. Nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple listing tool, annotations covering safety, schema covering all params, and an output schema present, the description is nearly complete. It could mention recursion behavior or sorting, but those are not essential for correct invocation. The provided details are sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described. The description adds context for the 'path' parameter (relative to server root) but does not elaborate on limit/offset or server defaults. Since the schema handles the heavy lifting, this is a baseline 3 with a minor enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('remote directory'), and adds a precise scoping detail ('relative to the server root'). This clearly differentiates from siblings like ftp_read (file content) and ftp_list_servers (server configuration) based on the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—this is the tool for listing directory contents—but does not explicitly mention when to prefer it over ftp_read or other siblings, nor does it state exclusions. The distinction is inferable from the name and title, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_list_serversList configured serversARead-onlyIdempotent
List all configured FTP/FTPS/SFTP servers (name, protocol, host, port, root, read-only, auth kind) and which is default. Never reveals passwords or keys.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint and idempotentHint, but the description adds a meaningful behavioral guarantee: 'Never reveals passwords or keys.' It also specifies the exact set of fields returned (name, protocol, host, port, root, read-only, auth kind, default), which is beyond what annotations provide. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the action and resource, then lists specifics and a security guarantee. No filler or redundant text. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to elaborate return values. It covers the purpose, lists output fields, and flags a security invariant. For a parameterless configuration-listing tool, nothing critical is absent. The only minor gap is explicit usage guidance, but that is covered under dimension 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the tool has zero parameters, the description cannot add parameter semantics. Per calibration, baseline for 0 params is 4. The description appropriately confirms no inputs are needed, and the schema is empty, so nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'configured FTP/FTPS/SFTP servers', enumerates the exact fields returned, and notes the default flag. It is unambiguous and distinguishes itself from sibling ftp_list (which likely lists files) by naming the resource type. The security note about not revealing passwords also clarifies its non-sensitive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to know configured servers) but provides no explicit guidance on when to choose it over alternatives like ftp_list or ftp_test. It does not state exclusions or prerequisites, relying on the tool name and purpose. A sentence like 'Use this to discover server names before invoking other ftp_* tools' would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_mkdirCreate a remote directoryAIdempotent
Recursively create a remote directory (relative to the server root).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote directory to create, relative to the server root. | |
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond annotations by stating the operation is recursive and relative to the server root. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action and the recursive behavior. Every word contributes to the tool's meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema descriptions, annotations for safety and idempotence, and an output schema present, the description covers the essential behavioral nuance (recursion) not already in the structured data. Nothing critical appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both path and server already described in the input schema. The description's mention of 'relative to the server root' repeats the schema's path description rather than adding new meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create'), a concrete resource ('remote directory'), and a key qualifier ('recursively') plus scope ('relative to the server root'). It clearly distinguishes this directory-creation tool from file-oriented siblings like ftp_upload and from operations like ftp_list or ftp_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool over alternatives such as ftp_upload or ftp_deploy, nor any mention of prerequisites, exclusions, or conditions. The only implied context is that it creates directories, leaving the agent to infer when this is the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_readRead a remote text fileARead-onlyIdempotent
Read a remote text file and return its content. Binary files are refused (use ftp_download instead).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote file path, relative to the server root. | |
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. | |
| max_bytes | No | Maximum bytes to read (default 262144, hard max 1048576). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the important behavioral detail that binary files are refused, which is beyond the annotations and helps the agent anticipate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence plus a parenthetical alternative. The core purpose is front-loaded, and every word earns its place—no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description covers core behavior and the binary refusal. It doesn't address error cases (e.g., file not found) but that's minor given the tool's simplicity and strong annotation coverage. Slightly more detail about failure behavior would push it to 5, but it's already solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (path, server, max_bytes) have descriptions in the schema, so the schema carries heavy weight. The tool description adds no new information about parameter meaning, but the high schema coverage makes this acceptable. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('read') and resource ('remote text file') and explicitly distinguishes itself from ftp_download by refusing binary files. An agent can immediately tell this is the text-reading tool versus the binary-download sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative (ftp_download) and the condition that triggers it (binary files are refused). This gives clear direction on when to use this tool versus the sibling, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_renameRename or move a remote entryADestructive
Rename or move a remote file or directory (both paths relative to the server root).
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. | |
| to_path | Yes | New remote path, relative to the server root. | |
| from_path | Yes | Existing remote path, relative to the server root. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate that. The description adds the path-relative-to-root context, but does not disclose what happens on failure, whether directories can be moved recursively, or whether overwriting is possible. With annotations covering the destructive nature, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the action and includes the key scoping detail about paths. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-required-parameter mutation tool with a full output schema and annotations covering destructiveness, the description is nearly complete. It could mention whether moving directories is supported or whether overwrites are allowed, but these are minor gaps given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the shared context that paths are relative to the server root, which reinforces the schema but doesn't add new meaning beyond it. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Rename or move') and resource ('remote file or directory'), and clarifies that paths are relative to the server root. This clearly distinguishes it from siblings like ftp_delete, ftp_upload, and ftp_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for renaming or moving remote entries, but does not explicitly state when to use this tool versus alternatives like ftp_upload or ftp_mkdir. It provides context (both paths relative to server root) but no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_testTest a server connectionARead-onlyIdempotent
Connect to a server, list its root directory, and report success.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that it lists the root directory and reports success, which is useful context beyond the annotations. However, it doesn't disclose what 'report success' returns or whether it throws on failure, which would be valuable for a test tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and includes the key behavioral detail ('report success'). Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple test tool with one optional parameter, full annotation coverage, and an output schema, the description is nearly complete. The only gap is that it doesn't specify what the success report looks like, but the output schema likely covers that, so the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter 'server' is already documented in the schema. The description doesn't add any additional meaning about the parameter beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Connect to a server, list its root directory, and report success') with a clear verb and resource. It distinguishes itself from siblings like ftp_list by focusing on testing connectivity rather than general listing, though it doesn't explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a connectivity test by mentioning 'report success', but it doesn't explicitly state when to use this tool versus alternatives like ftp_list or ftp_list_servers. The context is clear enough for an agent to infer the primary use case, but no exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ftp_uploadUpload a local fileADestructive
Upload one local file to the server, auto-creating parent directories. Remote path defaults to the file basename at the root.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. | |
| local_path | Yes | Local file path, absolute or relative to the server's configured localRoot. | |
| remote_path | No | Destination remote path, relative to the server root. Defaults to the local basename at the root. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, which signal a mutating operation. The description adds the auto-creation of parent directories and the default remote path behavior, which are valuable non-obvious details. It does not disclose potential overwrites of existing files, but the annotation covers the destructive aspect, so the description adds appropriate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence with no filler. The key behavioral details are front-loaded: action, auto-creation, and default path. Every word contributes, and it is neither under-specified nor verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present to document return values and annotations covering safety, the description is complete enough. It covers the primary behavior and defaults. It may not cover edge cases like what happens if the file doesn't exist, but given the context, it is adequately comprehensive for an upload tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents each parameter clearly. The description adds the default remote path behavior (basename at root) and clarifies the auto-creation of directories, which complements the schema. This is more than a simple restatement, adding value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: uploading a single local file to the server, with the specific behavior of auto-creating parent directories. It distinguishes itself from siblings like ftp_deploy (which likely uploads multiple files or directories) and ftp_download, and the default remote path behavior is clearly explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for single-file uploads and implicitly contrasts with ftp_deploy for bulk deployments, but it does not explicitly state when to use this versus alternatives. It provides no explicit exclusions, but the context is enough for an agent to infer the intended use.
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.
10 tool updates
v0.2.0- Changed
ftp_delete1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "deleted": { + "type": "boolean" + }, + "entry_type": { + "enum": [ + "file", + "directory" + ], + "type": "string" + }, + "path": { + "type": "string" + }, + "recursive": { + "type": "boolean" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + }, + "server": { + "type": "string" + } + }, + "required": [ + "server", + "path", + "entry_type", + "recursive", + "deleted", + "security_warning" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
ftp_deploy2 fields changed- changed
Input schema / properties / local_dir / descriptionPrevious value: -"Local directory to deploy (relative paths resolve against the process cwd)."New value: +"Local directory to deploy, absolute or relative to the server's configured localRoot." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "aborted_early": { + "type": "boolean" + }, + "complete": { + "type": "boolean" + }, + "duration_ms": { + "minimum": 0, + "type": "integer" + }, + "failed_count": { + "minimum": 0, + "type": "integer" + }, + "failures": { + "items": { + "additionalProperties": false, + "properties": { + "message": { + "type": "string" + }, + "path": { + "type": "string" + } + }, + "required": [ + "path", + "message" + ], + "type": "object" + }, + "type": "array" + }, + "failures_omitted": { + "minimum": 0, + "type": "integer" + }, + "mode": { + "enum": [ + "dry_run", + "deploy" + ], + "type": "string" + }, + "planned": { + "items": { + "additionalProperties": false, + "properties": { + "path": { + "type": "string" + }, + "size_bytes": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "path", + "size_bytes" + ], + "type": "object" + }, + "type": "array" + }, + "planned_omitted": { + "minimum": 0, + "type": "integer" + }, + "remote_base": { + "type": "string" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + }, + "server": { + "type": "string" + }, + "total_bytes": { + "minimum": 0, + "type": "number" + }, + "total_files": { + "minimum": 0, + "type": "integer" + }, + "uploaded": { + "items": { + "additionalProperties": false, + "properties": { + "path": { + "type": "string" + }, + "size_bytes": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "path", + "size_bytes" + ], + "type": "object" + }, + "type": "array" + }, + "uploaded_bytes": { + "minimum": 0, + "type": "number" + }, + "uploaded_count": { + "minimum": 0, + "type": "integer" + }, + "uploaded_omitted": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "mode", + "server", + "remote_base", + "total_files", + "total_bytes", + "uploaded_count", + "uploaded_bytes", + "failed_count", + "aborted_early", + "complete", + "duration_ms", + "security_warning", + "uploaded", + "uploaded_omitted", + "planned", + "planned_omitted", + "failures", + "failures_omitted" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
ftp_download2 fields changed- changed
Input schema / properties / local_path / descriptionPrevious value: -"Local destination path (relative paths resolve against the process cwd)."New value: +"Local destination path, absolute or relative to the server's configured localRoot." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "local_path": { + "type": "string" + }, + "overwritten": { + "type": "boolean" + }, + "remote_path": { + "type": "string" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + }, + "server": { + "type": "string" + }, + "size_bytes": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "server", + "remote_path", + "local_path", + "size_bytes", + "overwritten", + "security_warning" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
ftp_list3 fields changed- added
Input schema / properties / limitAdded value: +{ + "description": "Maximum entries to return (default 50, maximum 200).", + "maximum": 200, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "description": "Zero-based entry offset (default 0).", + "minimum": 0, + "type": "integer" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "count": { + "minimum": 0, + "type": "integer" + }, + "entries": { + "items": { + "additionalProperties": false, + "properties": { + "modified_at": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "size_bytes": { + "minimum": 0, + "type": "number" + }, + "type": { + "enum": [ + "dir", + "file", + "link" + ], + "type": "string" + } + }, + "required": [ + "name", + "type", + "size_bytes", + "modified_at" + ], + "type": "object" + }, + "type": "array" + }, + "has_more": { + "type": "boolean" + }, + "limit": { + "maximum": 200, + "minimum": 1, + "type": "integer" + }, + "next_offset": { + "anyOf": [ + { + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "offset": { + "minimum": 0, + "type": "integer" + }, + "path": { + "type": "string" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + }, + "server": { + "type": "string" + }, + "total": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "server", + "path", + "total", + "count", + "offset", + "limit", + "has_more", + "next_offset", + "entries", + "security_warning" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
ftp_list_servers2 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "configured_count": { + "minimum": 0, + "type": "integer" + }, + "default_server": { + "type": [ + "string", + "null" + ] + }, + "errors": { + "items": { + "additionalProperties": false, + "properties": { + "message": { + "type": "string" + }, + "server": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "server", + "message" + ], + "type": "object" + }, + "type": "array" + }, + "errors_omitted": { + "minimum": 0, + "type": "integer" + }, + "invalid_count": { + "minimum": 0, + "type": "integer" + }, + "servers": { + "items": { + "additionalProperties": false, + "properties": { + "auth": { + "enum": [ + "key", + "password" + ], + "type": "string" + }, + "connection_refused": { + "type": "boolean" + }, + "host": { + "type": "string" + }, + "is_default": { + "type": "boolean" + }, + "local_root_status": { + "type": "string" + }, + "name": { + "type": "string" + }, + "port": { + "exclusiveMinimum": 0, + "type": "integer" + }, + "protocol": { + "enum": [ + "ftp", + "ftps", + "sftp" + ], + "type": "string" + }, + "read_only": { + "type": "boolean" + }, + "root": { + "type": "string" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "name", + "protocol", + "host", + "port", + "root", + "read_only", + "auth", + "is_default", + "local_root_status", + "connection_refused", + "security_warning" + ], + "type": "object" + }, + "type": "array" + }, + "servers_omitted": { + "minimum": 0, + "type": "integer" + }, + "status": { + "enum": [ + "configured", + "missing", + "invalid" + ], + "type": "string" + }, + "valid_count": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "status", + "configured_count", + "valid_count", + "invalid_count", + "default_server", + "servers", + "servers_omitted", + "errors", + "errors_omitted" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
ftp_mkdir1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "created": { + "type": "boolean" + }, + "path": { + "type": "string" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + }, + "server": { + "type": "string" + } + }, + "required": [ + "server", + "path", + "created", + "security_warning" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Added
ftp_read - Added
ftp_rename - Changed
ftp_test1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "entries_visible": { + "minimum": 0, + "type": "integer" + }, + "host": { + "type": "string" + }, + "port": { + "exclusiveMinimum": 0, + "type": "integer" + }, + "protocol": { + "enum": [ + "ftp", + "ftps", + "sftp" + ], + "type": "string" + }, + "root": { + "type": "string" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + }, + "server": { + "type": "string" + } + }, + "required": [ + "server", + "protocol", + "host", + "port", + "root", + "entries_visible", + "security_warning" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
ftp_upload2 fields changed- changed
Input schema / properties / local_path / descriptionPrevious value: -"Local file path (relative paths resolve against the process cwd)."New value: +"Local file path, absolute or relative to the server's configured localRoot." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "local_path": { + "type": "string" + }, + "remote_path": { + "type": "string" + }, + "security_warning": { + "type": [ + "string", + "null" + ] + }, + "server": { + "type": "string" + }, + "size_bytes": { + "minimum": 0, + "type": "number" + } + }, + "required": [ + "server", + "local_path", + "remote_path", + "size_bytes", + "security_warning" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "CONFIG_REQUIRED", + "CONFIG_INVALID", + "SERVER_REQUIRED", + "SERVER_UNKNOWN", + "INVALID_ARGUMENT", + "READ_ONLY", + "TRANSPORT_POLICY", + "HOST_KEY_REJECTED", + "REMOTE_ROOT_REJECTED", + "PATH_REJECTED", + "NOT_FOUND", + "ALREADY_EXISTS", + "TRANSFER_LIMIT", + "TRANSFER_VERIFY", + "TARGET_CHANGED", + "CANCELLED", + "TIMEOUT", + "DEPLOY_PARTIAL", + "TRANSPORT_ERROR", + "OUTPUT_LIMIT", + "INTERNAL_ERROR", + "SCAN_LIMIT", + "CAPACITY_LIMIT" + ], + "type": "string" + }, + "effects": { + "enum": [ + "none", + "possible", + "confirmed" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "next_action": { + "enum": [ + "fix_input", + "fix_config", + "select_server", + "inspect_target", + "retry", + "contact_operator", + "none" + ], + "type": "string" + }, + "partial": { + "additionalProperties": false, + "properties": { + "completed_bytes": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "completed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "failed_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "final": { + "type": "boolean" + }, + "total_files": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "completed_files", + "completed_bytes", + "failed_files", + "final" + ], + "type": "object" + }, + "request_id": { + "format": "uuid", + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "schema_version": { + "const": 1, + "type": "number" + } + }, + "required": [ + "schema_version", + "code", + "message", + "retryable", + "request_id", + "next_action", + "effects" + ], + "type": "object" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
8 tool updates
v0.1.0- First observed
ftp_delete - First observed
ftp_deploy - First observed
ftp_download - First observed
ftp_list - First observed
ftp_list_servers - First observed
ftp_mkdir - First observed
ftp_test - First observed
ftp_upload
TDQS
Scored across 10 tools
Most tools have clear, distinct purposes (list, read, upload, download, mkdir, rename, delete, deploy, list servers, test). The only potential overlap is between ftp_deploy and ftp_upload, but ftp_deploy is for recursive directory uploads while ftp_upload is for a single file, so they are distinguishable with descriptions.
All tool names follow a consistent ftp_ prefix with a verb (deploy, list, test, read, upload, download, mkdir, rename, delete). The pattern is uniform and predictable, making it easy for an agent to infer functionality.
With 10 tools, the set is well-scoped for an FTP deployment server. Each tool covers a distinct operation (connection management, file operations, directory operations, deployment), and the count is within the ideal range of 3-15 tools.
The core FTP operations are covered: list, read, upload, download, mkdir, rename, delete, and deploy. Missing features like file permissions or detailed metadata (e.g., last modified time) are minor gaps, but the CRUD lifecycle is complete for file and directory operations.
Maintenance
Related MCP Connectors
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Related MCP Servers
- AlicenseAqualityDmaintenanceAn enterprise-grade MCP server for FTP and SFTP operations optimized for AI coding assistants, featuring smart synchronization, connection pooling, and unified diff patching.2837 npm3MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI agents SSH capabilities to execute commands, transfer files, and inspect remote systems through a preconfigured host list.41 npmMIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI assistants to perform development operations on remote servers via SSH, including executing commands, managing files, and browsing directories.1MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server for managing remote SSH servers, enabling AI agents to execute commands, transfer files, and perform deployment operations securely.MIT