Как выпустить MCP-сервер для вашего SaaS

Это решение о дистрибуции, а не интеграционная рутина

У продукта есть интерфейс для людей и API для разработчиков. MCP-сервер добавляет третью поверхность: ассистента, который у клиента уже открыт. Коммерчески это важно, потому что выбирает, вызывать ли вас, уже не человек, сравнивающий вкладки, а модель, сравнивающая описания инструментов.

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

Решите, что отдавать, до написания кода

Инстинкт — зеркалить REST API. Не поддавайтесь. API рассчитан на разработчика, который читает документацию и составляет вызовы; MCP-сервер потребляет модель, которая вызовет один инструмент, посмотрит результат и решит, что делать дальше.

Три вопроса быстро сужают выбор. О чём клиенты реально просят ассистента — а не какие эндпоинты существуют? Какие из этих задач закрываются одним вызовом, а не четырьмя? И какие результаты достаточно компактны, чтобы быть полезными в контекстном окне, а не 400 строк JSON, вытесняющие всё остальное?

Хороший первый сервер — три-шесть инструментов, каждый из которых доводит задачу до конца: найти объект, описать его состояние, внести небольшое безопасное изменение. Инструменты только на чтение — законная версия 1.0, и она выходит на неделю раньше.

Права — как у API-ключа, а не как у страницы документации

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

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

Ограничивайте частоту вызовов на соединение: модель в цикле повторов — необычайно усердный клиент.

Описания инструментов — это и есть продукт

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

Одна задача — один инструмент. Описывайте, когда его использовать и когда не нужно: «для счетов; для изменений подписки используйте billing_update» предотвращает больше неверных вызовов, чем любая настройка параметров. Предпочитайте перечисления свободным строкам, чтобы модель не изобрела несуществующий статус. И дайте пример аргумента: пример стоит трёх предложений спецификации.

Тестируйте в тех ассистентах, которыми пользуются ваши клиенты. Один и тот же сервер ведёт себя по-разному в разных клиентах, а «у меня в терминале работает» ничего не говорит о поверхности, где находятся покупатели.

Инструментируйте с первого дня

Логируйте каждый вызов: инструмент, аргументы, ответ, длительность. Без этого не ответить на единственно важные вопросы: какие инструменты используются, какие вызывают и бросают, потому что результат бесполезен, и какие не выбирают никогда.

Брошенные — самые информативные. Инструмент, чей результат ни к чему не ведёт, обычно возвращает слишком много, слишком мало или не в той форме, и починить это дешевле, чем добавлять функции, которых никто не просил.

Что выпустить первым

Сервер только на чтение с тремя хорошо описанными инструментами, привязанный к одному аккаунту, с логами и проверкой в двух клиентах. Это неделя работы, это безопасно публиковать, и это расскажет о желаниях клиентов больше, чем квартал планирования.