Списки MCP-серверов обычно отсортированы по числу звёзд на GitHub. Для выбора это худший из возможных критериев: популярность сервера ничего не говорит о том, что он может сделать с вашей машиной, а разброс здесь огромный — от «прочитать заголовок страницы» до «выполнить произвольную команду».
Ниже — тот же материал, отсортированный по уровню доступа. Сведения о конкретных пакетах меняются быстро, поэтому статья описывает категории и критерии выбора, а не фиксированный список имён; названия и возможности конкретных серверов проверяйте на момент подключения. Состояние на 25.08.2026.
#Что такое MCP-сервер и для кого этот текст
MCP-сервер — отдельная программа, которая сообщает ассистенту список своих инструментов и выполняет вызовы. Механика протокола разобрана отдельно, в статье про MCP как протокол подключения инструментов; здесь речь только о выборе.
Текст рассчитан на того, кто уже понял, зачем ему инструменты, и стоит перед списком из сотни пакетов, не понимая, с какого начать.
#Классификация по уровню доступа
Единственная классификация, которая имеет практический смысл, — по тому, что сервер может испортить.
| Категория | Уровень доступа | Что может испортить | Когда подключать |
|---|---|---|---|
| Поиск в сети | Чтение | Ничего | Первым |
| Документация и справочники | Чтение | Ничего | Первым |
| Файлы: только чтение | Чтение | Утечка содержимого | Вторым, с белым списком |
| Git: статус, лог, diff | Чтение | Утечка содержимого | Вторым |
| База данных: SELECT | Чтение | Утечка содержимого | Вторым, отдельной учёткой |
| Браузер: открыть и прочитать | Сетевой риск | Внутренние адреса сети | Осторожно, см. ниже |
| Файлы: запись | Запись | Данные на диске | Четвёртым, после логов |
| Заметки, задачи, календарь | Запись | Ваши записи | Четвёртым |
| Мессенджеры: отправка | Запись вовне | Репутацию | Отдельно и с подтверждением |
| Терминал, установка пакетов | Выполнение | Всё | В последнюю очередь или никогда |
Строка про браузер вынесена в отдельный уровень не для красоты. Инструмент, который открывает произвольный адрес, по формальному признаку «только читает», но при этом ходит по сети из вашей машины — и адрес может указывать во внутреннюю сеть. В Persona такие инструменты вынесены в отдельный класс unsafe_network в app/mcp/tool_policy.py именно потому, что «только чтение» здесь недостаточная характеристика. Отдельно про специфический риск чужой страницы — в разборе браузерного агента.
#Порядок подключения
Порядок важнее списка. Он рассчитан на то, чтобы к моменту первого пишущего инструмента у вас уже была видимость происходящего.
- Один читающий сервер. Поиск или справочник. Задача этапа — убедиться, что рантайм вообще работает, а модель попадает в синтаксис вызова.
- Проверка, что модель им пользуется. Задайте пять запросов, где инструмент нужен, и пять, где не нужен. Посмотрите логи. Если модель зовёт инструмент всегда или не зовёт никогда — проблема в описании, а не в сервере.
- Второй читающий: файлы или репозиторий. Здесь впервые появляется утечка как риск, поэтому сразу с белым списком каталогов.
- Пауза на неделю. Скучный, но самый полезный пункт: за неделю выяснится, какие вызовы происходят реально, а не какие вы вообразили.
- Первый пишущий инструмент. Один. Обратимый. С подтверждением на первое время.
- Всё остальное — по одному, с недельным интервалом.
Пункт про интервал существует потому, что при подключении трёх серверов сразу вы не сможете сказать, какой из них виноват в странном поведении. Аргументация в пользу такого порядка прав — в руководстве по белым спискам и правам по умолчанию.
#Сильные стороны экосистемы
Готовых интеграций действительно много. Для типовых сервисов — поиска, файлов, репозиториев, баз данных, трекеров — обычно уже есть работающий сервер, и написание своего не требуется.
Один сервер работает во всех клиентах. Настроенный для редактора кода сервер подключится и к другому ассистенту без изменений. Это и есть главная выгода протокола.
Обновление независимо от клиента. Изменился внешний API — обновился сервер, ваш ассистент этого не заметил.
Порог входа низкий. Минимальный сервер — это несколько десятков строк; подробности — в руководстве по написанию своего MCP-сервера.
#Слабые стороны
Раздел не короче предыдущего, потому что честный расклад именно такой.
Сервер — это чужой код с вашими правами. Запуск сервера через менеджер пакетов означает: скачать из интернета и выполнить от вашего имени. Никакой песочницы протокол не предоставляет. Практическая мера — ограничить список допустимых пусковых команд; в Persona первое слово команды запуска обязано принадлежать короткому списку известных запускателей, и конфигурация не может это обойти.
Качество описаний инструментов очень разное. Половина проблем «модель не пользуется сервером» — это описания, написанные для человека, а не для модели: без примеров значений, с синонимичными именами, без указания, что вернётся при ошибке.
Много инструментов — хуже выбор. Каждое описание занимает контекст. После определённого числа модель начинает путать похожие инструменты, и подключение очередного сервера ухудшает работу предыдущих.
Подвисания. Сервер, ушедший в сетевой запрос без таймаута, вешает ход ассистента целиком. Проверьте, что ваш клиент задаёт предел ожидания на вызов; в Persona он есть общий и настраивается отдельно на каждый сервер.
Никакой стандартной авторизации для локальных серверов. Сервер, запущенный по stdio, имеет ровно те права, что и запустивший процесс. Разграничение внутри — целиком на совести автора сервера.
#Лицензия и ограничения
Лицензия сервера — не формальность: она определяет, можно ли его использовать в рабочем контуре и можно ли его дорабатывать под себя. Три вещи, которые стоит проверить до подключения, а не после:
- Лицензия самого сервера. Разброс от разрешительных до копилефтных. Указание «open source» в README не заменяет файла лицензии в репозитории — проверяйте наличие файла.
- Условия сервиса, к которому он ходит. Сервер может быть свободным, а API за ним — платным, с лимитами и запретом на автоматизацию.
- Куда уходят данные. Сервер поиска отправляет ваш запрос поисковому провайдеру. Сервер базы данных — нет. Это разные истории с точки зрения приватности, и решать надо по каждому отдельно.
Отдельно про ключи: сервер, которому нужен ключ API, где-то его хранит. Уточните где. В Persona ключи участников лежат в таблице user_settings без шифрования, и это ровно та причина, по которой мы говорим об этом вслух, а не прячем в документацию.
#Кому что подойдёт
- Если вы только начинаете → один читающий сервер, неделя наблюдения, потом второй. Пишущие не трогайте, пока не прочитаете свои логи.
- Если вам нужен агент для работы с текстами и заметками → чтение файлов плюс запись в одну конкретную папку. Ничего больше не требуется.
- Если вы разработчик и хотите агента в проекте → git на чтение, поиск по коду, чтение файлов. Запись — руками через diff, а не инструментом.
- Если вам кажется, что нужен терминал → почти всегда не нужен: у него нет проверяемых параметров, поэтому ограничить его по смыслу невозможно, и защита остаётся только внешней.
И честная альтернатива: если у вас три инструмента и один клиент, отдельные серверы вам, вероятно, не нужны вовсе — прямые функции проще. Отличие инструмента от навыка и памяти, чтобы не подключать сервер там, где нужна инструкция, — в материале про навыки агента.
#Частые вопросы
#С какого MCP-сервера начать?
С читающего: поиск в сети или справочник. Он не может ничего испортить, поэтому на нём безопасно проверить, что рантайм работает и модель попадает в синтаксис вызова. Файлы — вторым шагом и сразу с ограничением по каталогам.
#Сколько серверов подключать одновременно?
По одному, с интервалом в несколько дней. При одновременном подключении нескольких вы не сможете понять, чей инструмент виноват в странном поведении, а суммарный объём описаний быстро начинает мешать модели выбирать.
#Опасно ли подключать сервер из чужого репозитория?
Это равносильно запуску чужой программы с вашими правами — протокол изоляции не даёт. Минимум: посмотреть, что именно запускается, ограничить список допустимых пусковых команд и держать общий выключатель рантайма под рукой.
#Почему модель не пользуется подключённым сервером?
Чаще всего дело в описаниях инструментов: расплывчатое назначение, отсутствие примера значения параметра, имя, похожее на другой инструмент. Проверяется быстро — задайте запрос, где инструмент очевидно нужен, и посмотрите в логе, был ли вызов вообще.
#Нужен ли отдельный сервер для работы с файлами?
Только если ваш клиент не умеет этого сам. Многие ассистенты уже содержат встроенные файловые инструменты с ограничением по каталогам, и добавление внешнего сервера с тем же назначением создаёт два похожих инструмента, между которыми модель будет выбирать наугад.
#Как понять, что сервер пора отключить?
Посмотрите в логи за месяц: если инструменты сервера не вызывались ни разу, он занимает контекст и не приносит пользы. Отключение неиспользуемых серверов улучшает выбор среди оставшихся — это самая дешёвая оптимизация из существующих.
#Вывод
Сортируйте серверы по уровню доступа, а не по популярности, и подключайте по одному с паузой на наблюдение. Читающие — сразу, пишущие — после того как научились читать собственные логи, выполняющие — в последнюю очередь или никогда.
Если после месяца работы сервер ни разу не вызывался — отключите его: он мешает модели выбирать среди тех, что действительно нужны.