Второй способ документация называет рекомендуемым - корни, которые клиент сообщает серверу. Важная деталь: корни, присланные клиентом, полностью заменяют серверный список разрешённых каталогов, а не добавляются к нему. Зато их можно менять на ходу, без перезапуска сервера.
И оговорка, на которую легко напороться: если сервер запущен без аргументов, а клиент корни не поддерживает или прислал пустой список, сервер упадёт с ошибкой при инициализации. Это сделано намеренно - без явно разрешённых каталогов он не запустится вообще.
Инструментов у него полтора десятка: чтение текста и медиафайлов, чтение нескольких файлов сразу, запись, правка, создание каталога, листинг, листинг с размерами, перемещение, поиск, дерево каталога, метаданные файла и отдельный инструмент, показывающий список разрешённых каталогов.
Версии по дате
Схема версий здесь необычная и объясняет, почему у разных серверов номера разные.
Версии выглядят как дата: 2026.8.18, 2026.7.10, 2026.7.4. Каждый пакет выпускается сам по себе, поэтому server-everything может стоять на августовской версии, а server-memory - на июльской. Общего номера у набора нет.
Отдельно описан способ публикации: пакеты уходят в реестры доверенной публикацией через OIDC прямо из системы сборки, без токенов реестра. Мелочь, но для официального репозитория с таким числом форков - правильная мелочь.
Что стоит знать заранее
Лицензия двойная. Новые вклады идут под Apache 2.0, существующий код остаётся под MIT. GitHub такое сочетание автоматически не классифицирует, поэтому обычной метки лицензии у репозитория нет.
Открытых задач много. На 25 августа 2026 года их 542 при семи серверах. Число включает и запросы на слияние, но порядок показательный: репозиторий с таким количеством звёзд собирает обращения обо всём протоколе, а не только о своих семи серверах.
Memory - это граф, а не блокнот. Сервер постоянной памяти оперирует сущностями, связями и наблюдениями, и в его README отдельно приведён пример системной подсказки, объясняющей модели, как этим пользоваться. Без такой подсказки толку от него мало.
Everything существует для проверки клиента. Это единственный сервер, задача которого - показать сразу все возможности протокола: подсказки, ресурсы и инструменты. Если пишете свой клиент, начинать отладку стоит с него.
Ссылки на исходники читаются как учебник. Раз серверы объявлены учебными примерами, разбирать их код - вполне законный способ применения. Семь разных серверов на двух языках дают более честное представление о протоколе, чем любое описание.
Ошибки первого знакомства
Искать здесь каталог серверов. Его тут нет, README отправляет в реестр протокола первым же блоком.
Ставить эталонный сервер в продакшен как есть. Проект прямо говорит, что это учебные примеры, а не готовые решения.
Копировать расширенный пример конфигурации целиком. В нём два архивных сервера, один из которых просит токен к GitHub.
Ждать поддержки архивных серверов. Одиннадцать из тринадцати не поддерживает никто, и гарантий безопасности для них нет.
Запускать Filesystem без разрешённых каталогов. Он не стартует - и это правильное поведение, а не поломка.
Думать, что корни добавляются к аргументам командной строки. Они их полностью заменяют.
Забыть про обёртку cmd /c на Windows. Для каждой записи с npx, но не для uvx.
Искать общий номер версии набора. Его нет, каждый пакет версионируется своей датой выпуска.
Если свести к одной фразе: это не магазин, а витрина с образцами - и ценность её в том, что образцы официальные, разобранные по косточкам и снабжены честным предупреждением, что в дело их надо доводить самому.
Источники
Статья сверена с репозиторием modelcontextprotocol/servers (ветка main) 25 августа 2026 года: README, дерево каталога src/, src/filesystem/README.md, src/memory/README.md, а также архивный репозиторий servers-archived. Количество серверов пересчитано по дереву. Даты выпуска пакетов сняты из реестров npm и PyPI в тот же день, звёзды и число открытых задач - через API GitHub. Пакеты выпускаются по отдельности и версионируются датой, поэтому номера у разных серверов различаются штатно.
.webp&w=3840&q=75)