A
licenseA
qualityD
maintenanceAn enterprise-grade MCP server for FTP and SFTP operations optimized for AI coding assistants, featuring smart synchronization, connection pooling, and unified diff patching.
28
37 npm
3
MIT
ftp-deploy-mcp
by alebgl77
ftp-deploy-mcp
Der Deploy-Button für KI-Coding-Agenten. Claude Code · Claude Desktop · Cursor · Windsurf · Trae · Antigravity → deine eigenen FTP / FTPS / SFTP-Server.
Version française → README.fr.md
Dein Agent führt den Deploy aus — du fragst einfach.
Warum
Jedes Webprojekt endet gleich: „Jetzt noch auf den Server damit.“
KI-Agenten schreiben großartigen Code, aber die meisten haben keinen sicheren Weg, ihn auf klassisches Hosting zu bringen — OVH, Ionos, Hostinger, o2switch und der Rest der Shared-Hosting-Welt läuft immer noch über FTP/SFTP, nicht über
git push.ftp-deploy-mcpgibt jedem MCP-Client einen Deploy-Weg zu deiner eigenen Infrastruktur — im selben Gespräch, in dem der Code geschrieben wurde.Anders als generische SSH-Exec-MCP-Server ist dieser gezielt für Datei-Deployments gebaut: eine Pfad-Jail, ein Read-only-Modus, Dry-run und Zugangsdaten, die nie in den Kontext des Modells gelangen.
Related MCP server: SSH MCP Server
Funktionen
Funktion | Beschreibung |
Multi-Server | FTP / FTPS / SFTP, beliebig viele Server in einer Konfiguration |
Ein-Befehl-Deploy | Rekursives Verzeichnis-Deployment, gitignore-ähnliche Ausschlüsse auf jeder Ebene, Dry-run |
Pfad-Jail | Jede Operation auf ein pro Server festgelegtes |
Read-only-Modus | Blockiert jeden Schreibzugriff auf Server, die unangetastet bleiben müssen |
FileZilla-Import | Konvertiert deine vorhandenen |
Auto-Setup | Konfiguriert 5+ MCP-Clients automatisch, mit zeitgestempelten Backups |
Doctor | Read-only-Diagnose von Node, Konfiguration, Servern und Client-Verdrahtung |
Zero Build | Reines ESM-JavaScript — Node-Stdlib + 5 kleine Abhängigkeiten |
Sicherheitsstandard | Reines FTP / unverifiziertes TLS wird standardmäßig verweigert, außer pro Server explizit erlaubt |
Praxisgetestet | 209 e2e-Assertions gegen echte lokale FTP + SFTP-Server |
Keine Telemetrie | Nichts verlässt deinen Rechner außer den Aufrufen an deine eigenen Server |
Schnellstart
git clone https://github.com/alebgl77/ftp-deploy-mcp.git && cd ftp-deploy-mcpFühre
install.cmdaus (Doppelklick, Windows) oder./install.sh(macOS / Linux).Starte deine IDE neu und sag deinem Agenten: „Deploy ./dist to prod.“
So funktioniert es
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. Was es ist
Ein MCP-Server (Model Context Protocol), der über stdio läuft und 10 Tools für
deinen Coding-Agenten bereitstellt. Zugangsdaten liegen in einer lokalen Konfigurationsdatei und gelangen nie in den Kontext des LLM.
Jede Remote-Operation ist auf ein root beschränkt, das du pro Server festlegst.
Benötigt Node.js >= 18. Keine nativen Abhängigkeiten, nichts zu kompilieren.
2. Installation
⚡ Ein-Befehl-Installation (empfohlen)
git clone https://github.com/alebgl77/ftp-deploy-mcp.git
cd ftp-deploy-mcpStarte dann den Assistenten:
Windows: Doppelklick auf
install.cmd.macOS / Linux:
./install.sh(falls nötig zuerstchmod +x install.sh).Oder manuell:
npm install && npm run setup.
Der setup-Assistent erledigt alles für dich:
erstellt oder importiert deine Serverkonfiguration (einschließlich FileZilla-Import deiner vorhandenen Sites);
testet die Verbindung zu jedem Server;
schreibt automatisch die Konfigurationsdateien der erkannten MCP-Clients (Claude Code, Claude Desktop, Cursor, Windsurf, Antigravity) — mit einem
.backup-<Datum>-Backup, bevor eine vorhandene Datei verändert wird;gibt einen einfügefertigen Block aus (und kopiert ihn) für Trae, das über seine UI konfiguriert wird.
Starte dann deine IDE neu und sag deinem Agenten z. B.: „Liste meine FTP-Server auf.“
Diagnose und Optionen
Jederzeit verfügbar: eine read-only-Diagnose (schreibt nichts):
npm run doctor # or: node src/index.js doctorSie zeigt die Node-Version, welche Konfigurationsdatei verwendet wird, die Serverliste (niemals
Passwörter) und — pro Client — ob der ftp-Eintrag mit dieser Installation verdrahtet ist.
setup-Optionen (node src/index.js setup [optionen]):
Option | Wirkung |
| Nicht-interaktiv (behält die vorhandene Konfiguration oder importiert mit |
| Zu konfigurierende Clients (Standard: alle erkannten). |
| Import aus FileZilla (Pfad optional → Standardort). |
| Ziel der Konfigurationsdatei (Standard |
| Überspringt die Verbindungstests. |
| Zeigt die geplanten Aktionen an und schreibt nichts. |
| Ersetzt einen vorhandenen, aber abweichenden |
(b) Globale Installation
npm install -g .Der Befehl ftp-deploy-mcp ist jetzt in deinem PATH; verwende ihn statt
node .../src/index.js.
(c) Auf npm veröffentlichen (für npx -y-Nutzung)
Wenn du dieses Paket unter deinem eigenen Namen auf npm veröffentlichst, können Clients es ohne vorherige Installation ausführen:
{ "command": "npx", "args": ["-y", "your-package-name"] }3. Serverkonfiguration
Erstelle eine Datei ftp-servers.json. Der Server sucht sie in dieser Reihenfolge (die erste
gefundene gewinnt):
--config <pfad>(Kommandozeilen-Flag)Umgebungsvariable
FTP_MCP_CONFIG(Pfad zur JSON-Datei)./ftp-servers.json(aktuelles Arbeitsverzeichnis)~/.ftp-mcp/servers.json
Vollständiges Schema
{
"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"
}
}
}Der Block oben verwendet
//-Kommentare nur zur Veranschaulichung. Die echte Datei muss strenges JSON sein (keine Kommentare). Sieheftp-servers.example.json.
Ersetzung durch Umgebungsvariablen
Jeder String-Wert darf ${ENV:VARIABLE_NAME} enthalten. Er wird beim Start durch den Wert der
Umgebungsvariable ersetzt. Ist die Variable nicht gesetzt, geben die Tools eine klare Fehlermeldung
mit dem Namen der fehlenden Variable aus.
"password": "${ENV:OVH_FTP_PASSWORD}"Sicherheitstipps
Bevorzuge SFTP. Reines
ftpundftpsmitinsecureTLS: truewerden standardmäßig abgelehnt: Bei diesen Transporten kann ein Netzwerkangreifer Zugangsdaten und Dateien abfangen oder verändern. Um sie trotzdem zu verwenden, musst du auf dem jeweiligen Server explizit"allowInsecure": truesetzen — und jeder Start-Log sowie jedes Tool-Ergebnis trägt dann eine sichtbare Sicherheitswarnung.Nimm
ftp-servers.jsonin deine.gitignoreauf (in diesem Repo bereits erledigt).Beschränke die Dateirechte (
chmod 600 ftp-servers.jsonunter Unix).Bevorzuge Umgebungsvariablen (
${ENV:…}) oder einen SSH-Schlüssel gegenüber einem Klartextpasswort.Verwende
readOnly: truefür Server, auf die der Agent niemals schreiben darf.Setze
rootso eng wie möglich: Die Jail verhindert jeden../-Ausbruch.
4. Import aus FileZilla
Hast du deine Sites bereits in FileZilla? Konvertiere sie:
# 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.jsonOhne --out wird das JSON auf stdout ausgegeben. Base64-kodierte Passwörter werden dekodiert; Sites
ohne gespeichertes Passwort erhalten einen ${ENV:<NAME>_PASSWORD}-Platzhalter (die Variable setzt du
selbst). Beispielausgabe:
{
"defaultServer": "my-site",
"servers": {
"my-site": {
"protocol": "ftp",
"host": "ftp.example.com",
"user": "deploy",
"password": "…",
"root": "/www/html"
}
}
}Achtung: Die erzeugte Datei enthält dekodierte Klartextpasswörter — halte sie aus der Versionskontrolle heraus (
.gitignore) und beschränke ihre Rechte (chmod 600).
Reine-FTP-Sites: Importierte Server mit
"protocol": "ftp"(wie im Beispiel oben) werden beim Verbindungsaufbau abgelehnt, bis du sie entweder aufsftp/ftpsumstellst oder explizit"allowInsecure": truebei ihnen setzt — der Import gibt für jede solche Site eine Warnung aus. Siehe Sicherheit.
5. Manuelle Client-Einrichtung (falls du setup nicht verwendest)
npm run setupschreibt diese Dateien automatisch (mit Backups). Dieser Abschnitt ist nur nützlich, wenn du lieber alles von Hand verdrahtest.
Ersetze /absolute/path/to/ftp-deploy-mcp/src/index.js durch den echten Pfad (Schrägstriche
/ funktionieren auch unter Windows). Wenn du das Paket auf npm veröffentlicht hast, ersetze
"command": "node", "args": ["…/src/index.js"] durch
"command": "npx", "args": ["-y", "dein-paketname"].
Die unten angegebenen Dateipfade sind die Standardpfade zum Zeitpunkt der Erstellung dieser Dokumentation; die UIs dieser Produkte entwickeln sich weiter, also prüfe bei Bedarf deren Doku.
Claude Code
.mcp.json im Projektstamm:
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Oder in einem Befehl:
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) oder .cursor/mcp.json (Projekt):
{
"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 hat keine stabile Konfigurationsdatei — alles läuft über die UI. KI-Chat-Panel →
Einstellungen/Zahnrad → MCP → Hinzufügen → Manuell konfigurieren, dann einfügen (das ist der Block,
den setup ausgibt und in deine Zwischenablage kopiert):
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Antigravity
Je nach Version ist die Datei eine der folgenden:
~/.gemini/antigravity/mcp_config.jsonVariante:
~/.gemini/config/mcp_config.json
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Du kannst auch das MCP-Panel des Agenten (MCP-Serververwaltung) → Server hinzufügen verwenden, mit derselben Struktur.
6. Die 10 Tools
Alle Remote-Pfade (path, remote_path, …) sind relativ zum Server-root und verwenden
POSIX-Stil. Der Parameter server ist immer optional (siehe Auflösung unten).
Tool | Parameter | Beschreibung |
| (keine) | Konfigurierte Server auflisten (Protokoll, Host, Port, Root, Nur-Lesen, Auth-Art). Niemals ein Passwort. |
|
| Verbinden, Root auflisten, Erfolg bestätigen. |
|
| Ein entferntes Verzeichnis auflisten (Verzeichnisse zuerst). |
|
| Eine Textdatei lesen (Standard 262144, max. 1048576 Bytes). Verweigert Binärdateien. |
|
| Eine Datei hochladen und übergeordnete Verzeichnisse erstellen. |
|
| Ein Verzeichnis rekursiv über eine einzige Verbindung bereitstellen, mit Standard-Ausschlüssen. |
|
| Eine Datei herunterladen; verweigert das Überschreiben, außer bei |
|
| Ein Verzeichnis erstellen (rekursiv). |
|
| Umbenennen oder verschieben. |
|
| Eine Datei löschen; ein Verzeichnis erfordert |
Serverauflösung: expliziter server-Parameter → defaultServer → der einzige Server, falls
es nur einen gibt → andernfalls ein Fehler, der die verfügbaren Namen auflistet.
Standard-Ausschlüsse für ftp_deploy: **/node_modules/**, **/.git/**, .env, .env.*,
*.log, .DS_Store, Thumbs.db, ftp-servers.json, **/.ftp-mcp/** (deine exclude-Globs
werden hinzugefügt; include schränkt auf passende Dateien ein). Muster ohne Schrägstrich
treffen auf jeder Tiefe zu (gitignore-artig): auch ein verschachteltes apps/api/.env wird
ausgeschlossen.
7. Beispiel-Prompts
„
./distauf demprod-Server bereitstellen."„Auflisten, was in
/wwwaufovhliegt."„Die
.htaccessvonprodholen und mir zeigen."„Einen Probelauf der Bereitstellung von
./buildnach/wwwmachen, damit ich sehen kann, was gesendet würde."„
index.old.htmlaufprodinindex.htmlumbenennen."
8. Sicherheit
Standardmäßig sichere Übertragung: einfaches FTP und FTPS mit deaktivierter Zertifikatsprüfung (
insecureTLS: true) werden verweigert, sofern der Servereintrag nicht explizit"allowInsecure": truesetzt. Wenn erlaubt, wird beim Start, inftp_list_servers, indoctorund an jedes Tool-Ergebnis für diesen Server eine Sicherheitswarnung angehängt.Root-Gefängnis: jede Operation wird normalisiert und dann verifiziert, dass sie unterhalb des Server-
rootbleibt. Jeder Ausbruchsversuch (../…) wird verweigert, selbst wennroot/ist.Nur-Lesen:
readOnly: trueblockiert jeden Schreibzugriff (Upload, Deploy, mkdir, rename, delete); Lesezugriffe funktionieren weiterhin.Zugangsdaten außerhalb der LLM: Passwörter, Passphrasen und Schlüssel werden niemals in der Tool-Ausgabe zurückgegeben.
Keine Telemetrie, keine ausgehenden Verbindungen außer zu deinen eigenen Servern.
Verbindungen pro Aufruf: jedes Tool öffnet eine Verbindung, führt die Operation aus und schließt sie — keine dauerhafte Sitzung.
9. Fehlerbehebung
Timeout / keine Verbindung (FTP): meist ist der Passivmodus durch eine Firewall blockiert. Stelle sicher, dass die Passiv-Ports deines Servers erreichbar sind.
SFTP-Schlüssel-Authentifizierung: setze
privateKeyPath(~wird expandiert) und, falls der Schlüssel verschlüsselt ist,passphrase. Prüfe die Berechtigungen des Schlüssels.„INSECURE CONNECTION REFUSED": Der Server verwendet einfaches FTP oder FTPS mit deaktivierter Zertifikatsprüfung. Stelle auf
sftp(oderftpsmit einem gültigen Zertifikat) um — oder, nur wenn du das Abhörrisiko vollständig akzeptierst — setze"allowInsecure": trueauf diesem Server.Selbstsigniertes FTPS:
insecureTLS: trueakzeptiert ein unverifiziertes Zertifikat. Dies deaktiviert den Schutz vor Man-in-the-Middle-Angriffen, erfordert daher ebenfalls"allowInsecure": trueund gibt bei jedem Aufruf eine Sicherheitswarnung aus. Bevorzuge die Installation eines gültigen Zertifikats.Implizites FTPS (Port 990): setze
implicitTLS: true(ftps-Protokoll) für ältere Server, die ab dem ersten Byte verschlüsseln, ohne einenAUTH TLS-Befehl.„no server configured": Die Datei wurde an keiner der 4 Speicherorte gefunden. Erstelle
ftp-servers.jsonoder übergib--config <path>/FTP_MCP_CONFIG=<path>.Der Client sieht die Tools nach
setupnicht: starte die IDE vollständig neu (schließe jedes Fenster, nicht nur das Projekt) und überprüfe dann die Verkabelung mitnpm run doctor.Der Server startet trotz ungültiger Konfiguration: das ist beabsichtigt (MCP-Clients mögen keine Server, die beim Start sterben). Der genaue Fehler wird beim Start auf
stderrausgegeben und bei jedem Tool-Aufruf zurückgegeben.
Entwicklung
npm test # runs the full smoke test (local FTP + SFTP, no external network)
node src/index.js --version
node src/index.js --helpMitwirken
Beiträge sind willkommen — siehe CONTRIBUTING.md für das Entwicklungs-Setup, die Prinzipien des Projekts und die PR-Checkliste.
Sicherheit
Eine Schwachstelle gefunden? Bitte kein öffentliches Issue eröffnen — siehe SECURITY.md für die Meldung auf privatem Weg.
Lizenz
MIT — siehe 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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete'), 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.
Usage Guidelines4/5
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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).
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema descriptions, 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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).
ParametersJSON Schema
| 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
A4.4/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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).
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the configured server. Defaults to the configured default, or the sole server. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior4/5
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.
Conciseness5/5
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.
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 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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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
A4.1/5.0
Scored across 10 tools
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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
ActivityActive
ResponsivenessNo issues
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
- 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