ftp-deploy-mcp
ftp-deploy-mcp
Кнопка деплоя для ИИ-агентов, пишущих код. Claude Code · Claude Desktop · Cursor · Windsurf · Trae · Antigravity → ваши собственные FTP / FTPS / SFTP-серверы.
Французская версия → README.fr.md
Ваш агент выполняет деплой — вам нужно только попросить.
Зачем
Любой веб-проект в итоге упирается в одно: «теперь залей это на сервер».
ИИ-агенты пишут отличный код, но у большинства из них нет безопасного способа доставить его на классический хостинг — OVH, Ionos, Hostinger, o2switch и весь остальной мир общего хостинга до сих пор работают на FTP/SFTP, а не на
git push.ftp-deploy-mcpдаёт любому MCP-клиенту путь для деплоя в вашу собственную инфраструктуру — в том же диалоге, где был написан код.В отличие от универсальных MCP-серверов, которые выполняют SSH-команды, этот специально создан для развёртывания файлов: изоляция путей (path jail), режим только для чтения, dry-run и учётные данные, которые никогда не попадают в контекст модели.
Related MCP server: SSH MCP Server
Возможности
Возможность | Описание |
Несколько серверов | FTP / FTPS / SFTP, любое количество серверов в одной конфигурации |
Деплой одной командой | Рекурсивный деплой каталога, исключения в стиле gitignore на любой глубине, dry-run |
Изоляция путей (path jail) | Каждая операция ограничена корнем |
Режим только для чтения | Блокирует любые записи на серверах, которые должны оставаться нетронутыми |
Импорт из FileZilla | Конвертация ваших существующих сайтов из |
Автонастройка | Автоматически настраивает 5+ MCP-клиентов, создавая резервные копии конфигураций с меткой времени |
Doctor | Read-only диагностика Node, конфигурации, серверов и подключения клиентов |
Без сборки | Чистый ESM JavaScript — стандартная библиотека Node + 5 небольших зависимостей |
Безопасно по умолчанию | Обычный FTP / непроверенный TLS отклоняются, если явно не разрешены для конкретного сервера |
Проверено в бою | 209 e2e-проверок на реальных локальных FTP + SFTP-серверах |
Без телеметрии | С вашей машины ничего не уходит, кроме вызовов к вашим собственным серверам |
Быстрый старт
git clone https://github.com/alebgl77/ftp-deploy-mcp.git && cd ftp-deploy-mcpЗапустите
install.cmd(двойной клик, Windows) или./install.sh(macOS / Linux).Перезапустите IDE и попросите агента: «Задеплой ./dist на прод».
Как это работает
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. Что это
MCP-сервер (Model Context Protocol), работающий через stdio и предоставляющий вашему агенту 10 инструментов для написания кода. Учётные данные хранятся в локальном конфигурационном файле и никогда не проходят через контекст LLM. Каждая удалённая операция ограничена корнем root, который вы выбираете для каждого сервера.
Требуется Node.js >= 18. Никаких нативных зависимостей, требующих компиляции.
2. Установка
⚡ Установка одной командой (рекомендуется)
git clone https://github.com/alebgl77/ftp-deploy-mcp.git
cd ftp-deploy-mcpЗатем запустите мастер настройки:
Windows: двойной клик по
install.cmd.macOS / Linux:
./install.sh(при необходимости сначала выполнитеchmod +x install.sh).Или вручную:
npm install && npm run setup.
Мастер setup сделает всё за вас:
создаст или импортирует конфигурацию серверов (включая импорт из FileZilla ваших существующих сайтов);
проверит подключение к каждому серверу;
автоматически запишет конфигурационные файлы обнаруженных MCP-клиентов (Claude Code, Claude Desktop, Cursor, Windsurf, Antigravity) — с резервной копией
.backup-<date>перед изменением любого существующего файла;выведет (и скопирует) готовый к вставке блок для Trae, который настраивается через его интерфейс.
Затем перезапустите IDE и попросите агента, например: «Список моих FTP-серверов».
Диагностика и опции
В любой момент доступна read-only диагностика (ничего не записывает):
npm run doctor # or: node src/index.js doctorОна выводит версию Node, какой конфигурационный файл используется, список серверов (никогда — пароли) и — для каждого клиента — подключена ли запись ftp к этой установке.
Опции setup (node src/index.js setup [options]):
Опция | Действие |
| Неинтерактивный режим (сохраняет существующую конфигурацию или импортирует с помощью |
| Клиенты для настройки (по умолчанию: все обнаруженные). |
| Импорт из FileZilla (путь необязателен → расположение по умолчанию). |
| Куда сохранить конфигурационный файл (по умолчанию |
| Пропустить проверки подключения. |
| Показать запланированные действия и ничего не записывать. |
| Заменить существующую, но отличающуюся запись |
(b) Глобальная установка
npm install -g .Команда ftp-deploy-mcp теперь в вашем PATH; используйте её вместо node .../src/index.js.
(c) Публикация в npm (для использования через npx -y)
Если вы опубликуете этот пакет в npm под своим именем, клиенты смогут запускать его без предварительной установки:
{ "command": "npx", "args": ["-y", "your-package-name"] }3. Конфигурация серверов
Создайте файл ftp-servers.json. Сервер ищет его в следующем порядке (срабатывает первый найденный):
--config <path>(флаг командной строки)переменная окружения
FTP_MCP_CONFIG(путь к JSON)./ftp-servers.json(рабочий каталог процесса)~/.ftp-mcp/servers.json
Полная схема
{
"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"
}
}
}Приведённый выше блок использует комментарии
//только в учебных целях. Настоящий файл должен быть строгим JSON (без комментариев). См.ftp-servers.example.json.
Подстановка переменных окружения
Любое строковое значение может содержать ${ENV:VARIABLE_NAME}. При запуске оно заменяется значением переменной окружения. Если переменная не задана, инструменты возвращают понятную ошибку с указанием отсутствующей переменной.
"password": "${ENV:OVH_FTP_PASSWORD}"Советы по безопасности
Предпочитайте SFTP. Обычные
ftpиftpsсinsecureTLS: trueотклоняются по умолчанию: на этих транспортах сетевой злоумышленник может перехватить или изменить учётные данные и файлы. Чтобы всё же использовать такой транспорт, необходимо явно задать для сервера"allowInsecure": true— и тогда каждый лог запуска и результат работы инструментов будет содержать заметное предупреждение о безопасности.Добавьте
ftp-servers.jsonв ваш.gitignore(в этом репозитории это уже сделано).Ограничьте права доступа к файлу (
chmod 600 ftp-servers.jsonв Unix).Предпочитайте переменные окружения (
${ENV:…}) или SSH-ключ вместо пароля в открытом виде.Используйте
readOnly: trueдля серверов, на которые агент никогда не должен записывать.Задавайте
rootмаксимально узким: изоляция не позволит выйти за пределы через../.
4. Импорт из FileZilla
У вас уже есть сайты в FileZilla? Сконвертируйте их:
# 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.jsonБез --out JSON выводится в stdout. Пароли в кодировке Base64 декодируются; сайты без сохранённого пароля получают заполнитель ${ENV:<NAME>_PASSWORD} (переменную вы задаёте сами). Пример вывода:
{
"defaultServer": "my-site",
"servers": {
"my-site": {
"protocol": "ftp",
"host": "ftp.example.com",
"user": "deploy",
"password": "…",
"root": "/www/html"
}
}
}Внимание: сгенерированный файл содержит декодированные пароли в открытом виде — не храните его в системе контроля версий (
.gitignore) и ограничьте права доступа (chmod 600).
Сайты на обычном FTP: импортированные серверы с
"protocol": "ftp"(как в примере выше) отклоняются при подключении, пока вы не переключите их наsftp/ftpsили явно не зададите для них"allowInsecure": true— импорт выводит предупреждение для каждого такого сервера. См. Безопасность.
5. Настройка клиентов вручную (если вы не используете setup)
npm run setupзаписывает эти файлы автоматически (с резервными копиями). Этот раздел пригодится, только если вы предпочитаете настроить всё вручную.
Замените /absolute/path/to/ftp-deploy-mcp/src/index.js на реальный путь (прямые слэши / работают и в Windows). Если вы опубликовали пакет в npm, замените "command": "node", "args": ["…/src/index.js"] на "command": "npx", "args": ["-y", "your-package-name"].
Расположения файлов ниже — стандартные на момент написания; интерфейсы этих продуктов развиваются, поэтому при необходимости сверяйтесь с их документацией.
Claude Code
.mcp.json в корне проекта:
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Или одной командой:
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 (глобально) или .cursor/mcp.json (для проекта):
{
"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 нет стабильного конфигурационного файла — всё делается через его интерфейс. Панель ИИ-чата → Settings/шестерёнка → MCP → Add → Configure Manually, затем вставьте (это блок, который setup выводит и копирует в буфер обмена):
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Antigravity
В зависимости от версии это один из файлов:
~/.gemini/antigravity/mcp_config.jsonвариант:
~/.gemini/config/mcp_config.json
{
"mcpServers": {
"ftp": {
"command": "node",
"args": ["/absolute/path/to/ftp-deploy-mcp/src/index.js"]
}
}
}Вы также можете воспользоваться панелью MCP агента (управление MCP-серверами) → добавить сервер, используя ту же структуру.
6. 10 инструментов
Все удалённые пути (path, remote_path, …) относительны корня root сервера и используют стиль POSIX. Параметр server всегда необязателен (см. порядок определения ниже).
Tool | Параметры | Описание |
| (нет) | Список настроенных серверов (протокол, хост, порт, корень, только чтение, тип аутентификации). Никогда не пароль. |
|
| Подключиться, вывести список корневого каталога, подтвердить успех. |
|
| Вывести список удалённого каталога (сначала каталоги). |
|
| Прочитать текстовый файл (по умолчанию 262144, максимум 1048576 байт). Отказывается читать бинарные файлы. |
|
| Загрузить один файл с созданием родительских каталогов. |
|
| Рекурсивно развернуть каталог по одному соединению, с исключениями по умолчанию. |
|
| Скачать файл; отказывается перезаписывать, если не указано |
|
| Создать каталог (рекурсивно). |
|
| Переименовать или переместить. |
|
| Удалить файл; для каталога требуется |
Определение сервера: явный параметр server → defaultServer → единственный сервер,
если он только один → в противном случае ошибка со списком доступных имён.
Исключения по умолчанию для ftp_deploy: **/node_modules/**, **/.git/**, .env, .env.*,
*.log, .DS_Store, Thumbs.db, ftp-servers.json, **/.ftp-mcp/** (ваши glob-шаблоны
exclude добавляются; include ограничивает набор соответствующими файлами). Шаблоны без
слеша совпадают на любой глубине (как в gitignore): вложенный apps/api/.env тоже исключается.
7. Примеры запросов
«Развернуть
./distна сервереprod.»«Показать, что находится в
/wwwнаovh.»«Забрать
.htaccessсprodи показать мне.»«Сделать пробный запуск развёртывания
./buildв/www, чтобы я увидел, что будет отправлено.»«Переименовать
index.old.htmlвindex.htmlнаprod.»
8. Безопасность
Безопасные транспорты по умолчанию: обычный FTP и FTPS с отключённой проверкой сертификата (
insecureTLS: true) отклоняются, если в записи сервера явно не указано"allowInsecure": true. Если разрешено, предупреждение о безопасности показывается при запуске, вftp_list_servers, вdoctorи добавляется к каждому результату вызова инструмента для этого сервера.Корневая изоляция: каждая операция нормализуется, а затем проверяется, что она остаётся в пределах корня (
root) сервера. Любая попытка выхода за пределы (../…) отклоняется, даже еслиrootравен/.Только чтение:
readOnly: trueблокирует все операции записи (загрузка, развёртывание, mkdir, переименование, удаление); чтение продолжает работать.Учётные данные вне LLM: пароли, кодовые фразы и ключи никогда не возвращаются в результатах работы инструментов.
Никакой телеметрии, никаких исходящих соединений, кроме как к вашим собственным серверам.
Соединение на каждый вызов: каждый инструмент открывает соединение, выполняет операцию и закрывает его — постоянной сессии нет.
9. Устранение неполадок
Тайм-аут / невозможно подключиться (FTP): обычно пассивный режим блокируется брандмауэром. Убедитесь, что пассивные порты вашего сервера доступны.
Аутентификация по ключу SFTP: укажите
privateKeyPath(~раскрывается) и, если ключ зашифрован,passphrase. Проверьте права доступа к ключу.«INSECURE CONNECTION REFUSED»: сервер использует обычный FTP или FTPS с отключённой проверкой сертификата. Переключите его на
sftp(илиftpsс действительным сертификатом) или — только если вы полностью принимаете риск перехвата — укажите"allowInsecure": trueдля этого сервера.Самоподписанный FTPS:
insecureTLS: trueпринимает непроверенный сертификат. Это отключает защиту от атак «человек посередине», поэтому также требует"allowInsecure": trueи выводит предупреждение о безопасности при каждом вызове. Предпочтительнее установить действительный сертификат.Неявный FTPS (порт 990): укажите
implicitTLS: true(протоколftps) для устаревших серверов, которые шифруют с первого байта, без командыAUTH TLS.«no server configured»: файл не найден ни в одном из 4 мест. Создайте
ftp-servers.jsonили передайте--config <path>/FTP_MCP_CONFIG=<path>.Клиент не видит инструменты после
setup: полностью перезапустите IDE (закройте все окна, а не только проект), затем проверьте подключение с помощьюnpm run doctor.Сервер запускается, несмотря на недопустимую конфигурацию: это сделано намеренно (клиенты MCP не любят серверы, которые умирают при запуске). Точная ошибка выводится в
stderrпри запуске и возвращается при каждом вызове инструмента.
Разработка
npm test # runs the full smoke test (local FTP + SFTP, no external network)
node src/index.js --version
node src/index.js --helpУчастие в разработке
Вклад приветствуется — см. CONTRIBUTING.md с описанием настройки разработки, принципов проекта и чек-листа для pull request.
Безопасность
Нашли уязвимость? Пожалуйста, не открывайте публичный issue — см. SECURITY.md о том, как сообщить о ней конфиденциально.
Лицензия
MIT — см. 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