MCP-сервер: как подключить к своей модели

MCP решает скучную, но дорогую проблему: одни и те же инструменты приходится описывать заново под каждое приложение. Протокол задаёт единый способ рассказать о доступе к базе, файлам или внутреннему сервису — и любой совместимый клиент этот набор видит. Выгода появляется не сразу: при одном приложении проще описать функции напрямую, а протокол окупается, когда клиентов несколько или инструменты переиспользуются между командами. Разбираем, что именно даёт подключение, где оно лишнее, и главное — какие права выдавать серверу, потому что здесь ошибка стоит дороже всего.

Что это меняет на практике

Начнём с того, что было до.

Обычный вызов функций устроен так: вы описываете инструменты в коде своего приложения, модель предлагает вызов, ваш код выполняет. Описание живёт внутри приложения, и второе приложение описывает те же инструменты заново.

MCP выносит описание в отдельный сервер. Он говорит, какие инструменты есть и что они принимают, а клиенты подключаются к нему. Один сервер — много клиентов.

Что из этого следует:

Инструменты переиспользуются. Доступ к внутреннему сервису описан один раз.

Обновление в одном месте. Изменился набор инструментов — все клиенты увидели новый набор.

Клиенты взаимозаменяемы. Смена приложения не требует переписывать интеграцию.

Общий разбор идеи — в материале что такое MCP простыми словами. Здесь речь о практике подключения.

Что не меняется

Три вещи, которые важно понимать до внедрения.

Модель по-прежнему ничего не выполняет. Она предлагает вызов, выполняет клиент. Между намерением и действием стоит код — как и раньше.

Описания по-прежнему часть промпта. Инструменты MCP-сервера уходят в модель при каждом обращении и оплачиваются как входные токены. Сервер с тридцатью инструментами — это постоянный довесок к каждому запросу.

Качество выбора по-прежнему зависит от описаний. Модель выбирает инструмент по тексту описания, и плохо описанный инструмент MCP не спасёт.

Третий пункт особенно важен: протокол решает задачу переиспользования, а не задачу понятности. Описания придётся писать так же тщательно.

Когда протокол не нужен

Четыре ситуации, где он добавляет сложности без выгоды.

Одно приложение и один набор инструментов. Прямое описание функций проще и отлаживается быстрее.

Инструменты меняются вместе с приложением. Тогда вынесение их наружу только добавляет шаг синхронизации.

Инструментов два-три. Инфраструктура вокруг них дороже их самих.

Нужна максимальная предсказуемость. Дополнительный слой — это дополнительная точка отказа: сервер может быть недоступен, версия может разойтись.

Честный признак необходимости: у вас больше одного клиента, который должен видеть одни и те же инструменты. Всё остальное — преждевременно.

Права: главный вопрос

Раздел, который важнее всех остальных.

MCP-сервер — это набор возможностей, выданных модели. И выдаются они не одному приложению, а всем подключённым клиентам. Значит вопрос «что умеет сервер» становится вопросом «что может сделать любой клиент, который к нему подключится».

Четыре правила:

Минимальный набор под задачу. Не «доступ к базе», а конкретные операции: получить статус заказа по номеру, найти документ по идентификатору.

Разделяйте чтение и запись. Отдельные серверы или хотя бы отдельные наборы прав. Читающий сервер безопасен принципиально, пишущий требует подтверждений.

Никаких универсальных инструментов. Функция, принимающая произвольный код или запрос к базе, отдаёт модели всё, к чему у сервера есть доступ, и никакая проверка аргументов этого не исправит.

Подтверждение на необратимом. Отправка, платёж, удаление — только через человека.

Причина строгости прямая: в контекст попадает внешний текст, и он может содержать инструкцию. Всё, что умеет сервер, потенциально доступно через такой текст — как защититься от промпт-инъекции и какие доступы давать агенту.

Порядок подключения

Шесть шагов, если делаете впервые.

1. Выберите одну задачу. Не «дать доступ ко всему», а конкретный сценарий, который сейчас делается руками.
2. Опишите два-три инструмента. Название говорящее, описание отвечает на вопрос «когда это вызывать», аргументы с типами и примерами.
3. Начните с чтения. Никаких изменяющих операций в первой версии.
4. Подключите один клиент и проверьте на двадцати реальных задачах. Смотрите не только на результат, но и на то, какой инструмент модель выбирала — как ставить такие замеры.
5. Посмотрите на расход. Описания уходят при каждом обращении; если инструментов станет много, это будет видно в счёте — как считать.
6. Добавляйте изменяющие операции по одной, каждую с подтверждением.

Третий шаг стоит соблюдать даже при уверенности: читающий сервер, подключённый к нескольким клиентам, — это уже полезно, и он не может ничего испортить.

Что ломается чаще всего

Пять типовых проблем.

Инструментов слишком много. Чем длиннее список, тем чаще модель промахивается с выбором. Пять-восемь работают заметно лучше двадцати.

Описания похожи. Два инструмента с близкими формулировками — гарантированная путаница. Разводите явно: «использовать, только если есть номер заказа».

Сервер недоступен, а клиент этого не показывает. Пользователь видит «модель не смогла», хотя проблема в инфраструктуре — как различать виды отказов.

Версии разошлись. Клиент ожидает набор, которого сервер уже не отдаёт.

Нет логов вызовов. Что было предложено, что выполнено, что вернулось — без этого разобраться в неверном поведении не по чему — что писать в логи.

Как это связано с моделями

Практическое уточнение, потому что здесь путаница.

MCP живёт на стороне клиента и вашего сервера, а не на стороне маршрута к модели. Провайдер доступа отдаёт вам модель по совместимому протоколу; подключение инструментов настраивается в приложении.

Что от модели всё-таки зависит: насколько надёжно она пользуется инструментами. Поддержка вызова функций у разных позиций проверена по-разному, и в выдаче GET /v1/models это видно полями capabilities — у большинства позиций каталога они помечены unknown, то есть проверка не проводилась. Это не «не работает», но и закладывать без своего теста нельзя — как читать поля.

В каталоге на 6 сентября 2026 года 56 позиций в шестнадцати семействах, у 34 открыт чат-протокол. Проверить, как конкретная позиция обращается с вашими инструментами, — вопрос вечера и небольшой выборки.

Что записать до подключения

Короткий документ на одну страницу, который стоит завести до первого клиента.

Список инструментов и что каждый делает. Не в коде, а словами — так, чтобы понял человек, не писавший сервер.

Что каждый инструмент может испортить в худшем случае. Именно испортить, а не «сделать». Этот столбец и определяет, какие операции требуют подтверждения.

Кто подключён. Список клиентов, имеющих доступ. Он растёт незаметно, и через полгода никто не помнит, кто ещё видит ваши инструменты.

Как отозвать доступ. Проверенная процедура, а не предположение, что «мы просто выключим сервер».

Четвёртый пункт стоит проверить на практике один раз, пока подключён один клиент. Отзыв доступа, впервые выполняемый в момент, когда он срочно понадобился, — плохой план.

И общее правило, которое стоит держать при росте: каждый новый инструмент делает выбор модели чуть менее точным и каждый запрос чуть дороже. Список стоит пересматривать раз в квартал и вычёркивать то, что ни разу не вызывалось.

Чего мы не утверждаем

Не описываем формат протокола. Спецификация развивается; смотрите первоисточник.

Не рекомендуем конкретные реализации серверов. Их много, выбор зависит от стека.

Не сравниваем модели по надёжности вызова инструментов. Своих замеров мы не делали.

Не обещаем совместимости конкретного клиента. Проверяйте на своей связке.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог: если одна позиция плохо обращается с вашими инструментами, проверка соседней — правка строки в конфигурации.

Платные текстовые модели доступны сразу на приветственном бонусе. Отдельный ключ под сценарий с инструментами стоит завести с первого дня — и для учёта, и чтобы ограничить ущерб пределом расхода.

Что держать в голове

MCP решает проблему переиспользования инструментов между клиентами и не решает проблему их качества: описания придётся писать так же тщательно, и в модель они уходят при каждом обращении.

Главное при подключении — права. Сервер выдаёт возможности не одному приложению, а всем подключённым, поэтому начинать стоит с чтения и минимального набора операций.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить свои инструменты на нескольких моделях: keydealer.ru/login.