Удалённый сервер MCP в действии: новая точка входа для SaaS-продуктов в эпоху ИИ

У SaaS-продуктов есть давняя проблема: время до получения пользы слишком велико. Много пользователей уходят, так и не достигнув момента «ага».

Мы не раз улучшали процесс онбординга в Logto. Это помогло, но узкое место не исчезло. Всё равно приходится читать документацию, просматривать туториалы, устанавливать SDK, настраивать конфиги, писать код и потом отлаживать последние 10 %, прежде чем что-то заработает.

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

Один запрос может провести тебя от нуля до рабочей интеграции. Агент не просто генерирует код, а ещё создаёт и настраивает приложение Logto в твоём тенанте. Всё это — прямо из IDE. (Попробуй Logto MCP Server)

В этой статье я поделюсь нашим опытом и мыслями о создании Logto MCP Server, включая:

• MCP против Agent Skills: почему мы выбрали MCP
• Проблемы, с которыми мы столкнулись при запуске MCP-сервера и как мы их решили
• Как мы проектируем MCP-инструменты и как тебе стоит проектировать свои
• Наши ожидания от будущего MCP

MCP против Agent Skills: почему мы выбрали MCP#

Прежде чем решать, как ИИ должен получать доступ к Logto, мы рассмотрели два варианта: MCP-серверы и Agent Skills.

Серверы MCP бывают двух типов: локальные и удалённые.

Локальный MCP-сервер работает на машине пользователя. Требуется установка сервиса, настройка окружения, ввод учётных данных или специальные способы входа. По использованию и распространению он очень похож на скиллы.

Удалённый MCP-сервер размещается на сервере. Пользователи подключаются по URL и авторизуются через OAuth. Эта модель ближе к расширению SaaS-сервисов.

С точки зрения структуры, Agent Skill — это сочетание «бизнес-логики + базовых возможностей». Эти возможности могут быть инструментами, CLI или API-вызовами. MCP-инструменты могут предоставлять этот слой в едином виде.

Ключевой вопрос — не в том, как реализуются возможности, а в том, как они доставляются пользователям.

• Agent Skills предоставляют: полный локальный тулчейн (пакет Skill + локальное окружение выполнения + API-ключи или платформенные данные доступа + CLI-инструменты + установка, настройка, обновление и сопровождение).
  По сути, ты отдаёшь возможность пользователю, чтобы он сам всё запускал.

• Удалённые MCP-серверы предоставляют: удалённую сервисную точку входа (URL + вход через OAuth).
  По сути, ты предоставляешь возможность как сервис.

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

Пользовательский опыт#

Agent Skills обычно зависят от платформенных API или CLI. Пользователь должен сначала создать API-ключи либо установить и войти в CLI. Эти шаги несложные, но повышают порог входа.

MCP-серверы поддерживают OAuth. Пользователь входит через свою учётную запись SaaS. Это похоже на «Войти через Google».

Для пользователя использовать MCP-сервер просто: ввести URL, войти, подключиться. Именно такой опыт мы хотим предложить.

Охват экосистемы#

На сайте MCP уже 104 ИИ-приложения поддерживают MCP, включая такие инструменты как VS Code, Cursor и Windsurf.

Agent Skills пока платформенно-зависимы. Даже если много платформ их поддерживают, при публикации MCP-сервера пользователи могут сразу пользоваться им. А если опубликовать Skill, только пользователи нужной платформы смогут его применить.

MCP также входит в Agentic AI Foundation (AAIF). Это протокольный стандарт. Экосистема будет только расти. Это делает MCP достойным долгосрочных инвестиций.

Издержки на доставку и сопровождение#

Agent Skills зависят от API или CLI платформы, и это быстро влечёт проблемы:

• Что, если API изменится?
• Что, если CLI станет несовместимым?
• Как обновлять и распространять Skill?

Также придётся распространять CLI, управлять разбросанными данными доступа, поддерживать разные платформы и объяснять, как обновлять всё пользователям. Окупаемость низкая.

MCP-серверы гораздо проще. Пользователь подключается по URL. Он всегда ведёт на последнюю версию. Когда мы обновляем MCP-сервер, пользователь получает обновление при следующем подключении. Никаких обновлений с его стороны не требуется. Если API изменятся, мы обновим их внутри MCP-сервера.

У большинства SaaS-продуктов уже есть сильная инфраструктура: стабильные API и зрелая auth-система. MCP-сервер логично вписывается как «ИИ-интерфейс» для API, так же как админ-консоль — ещё один интерфейс поверх тех же API.

Для Logto выбор MCP-сервера идеально укладывается в нашу архитектуру и использует наши сильные стороны.

Это ещё и централизует все запросы в одну точку. Проще логи и аудит. Права понятны: ИИ может делать только то, что разрешил пользователь. Эта модель чиста с точки зрения enterprise- и compliance-сценариев.

Проблемы, с которыми мы столкнулись при запуске MCP-сервера, и как мы их решили#

MCP не идеален. Большинство проблем связаны с незрелостью экосистемы. Со временем это улучшится. Пока мы используем обходные решения, чтобы покрыть реальные потребности.

Фрагментированная поддержка возможностей MCP#

Спецификация MCP описывает много возможностей, но поддержка на клиентах разная:

• Инструменты: широко поддерживаются
• OAuth: хорошо работает в VS Code; для инструментов типа Cursor нужен мост mcp-remote
• Другие возможности (ресурсы, подсказки, инструкции): поддержка непоследовательная

Сейчас инструменты — это самая надёжная общая прослойка (на MCP Community Page можно посмотреть, что поддерживает каждый клиент).

Поэтому у нас простой подход: строить всё на инструментах.

LLM не знает, как использовать твои инструменты#

Это вопрос бизнес-уровня.

В Agent Skills бизнес-логика и контекст заложены в один пакет. LLM знает, как ими пользоваться. MCP предоставляет только инструменты. После подключения LLM не знает:

• Сценариев использования
• Порядка вызовов
• Бизнес-ограничений

В MCP есть концепция Instructions, но не все клиенты поддерживают её. К тому же, инструкции полностью загружаются в контекст при подключении, что тратит токены впустую.

Можно было бы добавлять объяснения в описание инструментов, но тут две проблемы:

• Описания становятся сложными. Мультиинструментальные сценарии быстро запутываются и сложно поддерживать.
• Чем больше инструментов — тем больше контекстное окно занимают описания.

Наше решение: предоставить инструмент getInstructions

Суть проста: если Instructions плохо поддерживаются — делаем их инструментом.

LLM может вызывать getInstructions по необходимости.
Для задачи А вызывается getTaskAInstructions. MCP-сервер возвращает подсказку, как выполнить задачу и как использовать другие инструменты.

Сложная бизнес-логика остаётся за инструкциями-инструментами. Остальные инструменты просты. Их описания касаются только их функций.

Похоже на Agent Skills: подсказки подгружаются по требованию. Это эффективнее глобальных Instructions, потому что ничего лишнего не грузится в контекст.

LLM может утечь твои секреты#

Во многих SaaS-продуктах нельзя раскрывать некоторые секреты (например, client secrets, API-ключи, ключи подписи webhook). Утечка даст возможность другим выдавать себя за тебя или получить прямой доступ к ресурсам.

Проблема LLM — чат не является безопасным каналом. Диалоги могут логироваться, копироваться, передаваться или попадать в логи отладки. Нельзя полагаться, что «только я и модель это видим». Передавать LLM долгоживущие секреты либо просить вывести их — большой риск.

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

Чтобы одновременно сделать онбординг простым и не жертвовать безопасностью:

• Используем временные секреты на этапе интеграции

  В процессе чата MCP-сервер отдаёт только кратковременные секреты (например, действительные 1 час). Их хватает, чтобы интеграция заработала, и к запуску в продакшн они обычно уже невалидны. Затем разработчик создаёт и подставляет production-секрет вне чата.

• Явно ограничиваем границы безопасности

  Мы явно предупреждаем: не создавайте, не вставляйте и не храните production-секреты в чате. Также напоминаем разработчикам, что даже переменные окружения или конфиги могут утечь, если агент/LLM может их читать через инструменты или косвенным доступом. Production-секреты должны храниться только там, где нет AI-интеграции.

• Продакшн-секреты вне чата; направляем пользователя в консоль

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

Как мы проектируем MCP-инструменты#

Наш путь#

В Logto есть полный Management API. Первая идея: отдать каждый endpoint как MCP-инструмент.

Но быстро выяснилось, что это не работает.

Во-первых, взрыв контекста. В Logto много API. Маппинг один к одному забивает контекстное окно. Каждое описание инструмента расходует токены.

Во-вторых, теряется смысл. API — атомарные кирпичики для разработчиков. Но пользователи Logto MCP Server не строят системы. Им важно завершить задачи. Сколько есть API — им неважно.

Пример: у Logto есть API sign-in-experience для брендинга, способов входа, регистрации, политики безопасности.
Мы сначала думали, как раскрыть все параметры и научить LLM комбинировать вызовы.

Но это не тот подход. Пользователь не вызывает API. Он хочет сменить брендирование или настроить способы входа.

Поэтому инструменты — это updateBranding, updateSignInMethod, updateSignUpMethod. Составление вызовов делает MCP-сервер внутри.

Logto MCP Server должен восприниматься как продукт, а не просто обёртка над API. Это «ещё одна админ-консоль».

Как проектировать MCP-инструменты#

Правило оформляется так:

• Если пользователи твой сервис используют напрямую (как консоль) — инструменты должны быть бизнес-ориентированы.
• Если ты даёшь базовые возможности для чьих-то интеграций — инструменты лучше делать атомарными. Например, файловый MCP-сервер с read_file, write_file, а агенты сами их комбинируют.

Дополнительные принципы:

• Держи логику и описания инструментов простыми во имя экономии контекста.
• Для сложных сценариев используй инструменты getInstructions — грузим подсказки по запросу. Они тоже должны быть кратко описаны.

Наши ожидания от будущего MCP#

Пока создавали MCP-сервер, мы думали, что могло бы улучшить экосистему.

Передача возможностей уровня Skill#

Иногда MCP-серверы должны давать не только инструменты, но и объяснения, как их комбинировать — как Agent Skills.

Это часто нужно в SaaS. Например — GitHub MCP Server, Logto MCP Server, различные аналитические платформы. Пользователь ждёт workflow, а не атомарные вызовы.

Инструмент getInstructions — костыль. Лучше, если бы поддержка закладывалась на уровне протокола.

Включение MCP на уровне сессии#

Клиенты подключают много MCP-серверов, но не в каждой сессии нужны все. Включать/отключать MCP на уровне сессии можно, чтобы экономить контекст.

Изоляция контекста для вызовов инструментов MCP#

Вызовы MCP-инструментов сильно расходуют контекст. Если обрабатывать их подпроцессами (sub-agent), основной диалог сможет получать только сжатые ответы.

Заключение#

Это наш опыт по созданию удалённого MCP-сервера.

Если ты хочешь попробовать, переходи на Logto MCP Server или присоединяйся к нашему Discord, чтобы обменяться реальным опытом с сообществом.

В следующих постах мы расскажем подробнее о деталях архитектуры и OAuth-потоке.