Удалённый сервер MCP в действии: новая точка входа для SaaS-продуктов в эпоху ИИ
Узнай, как создать удалённый сервер MCP для своего SaaS-продукта. Мы делимся опытом сравнения MCP и Agent Skills, интеграцией OAuth и проектированием MCP-инструментов.
YijunDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
У SaaS-продуктов есть давняя проблема: время до получения пользы слишком велико. Много пользователей уходят, так и не достигнув момента «ага».
Мы не раз улучшали процесс онбординга в Logto. Это помогло, но узкое место не исчезло. Всё равно приходится читать документацию, просматривать туториалы, устанавливать SDK, настраивать конфиги, писать код и потом отлаживать последние 10 %, прежде чем что-то заработает.
Мы попробовали другой подход: удалённый сервер MCP как нативную для IDE управляющую плоскость Logto. Вместо того чтобы кликать по админ-консоле, ты настраиваешь Logto и генерируешь код интеграции прямо в диалоге — там, где создаёшь приложение.
Один запрос может провести тебя от нуля до рабочей интеграции. Агент не просто генерирует код, а ещё создаёт и настраивает приложение Logto в твоём тенанте. Всё это — прямо из IDE. (Попробуй Logto MCP Server)
В этой статье я поделюсь нашим опытом и мыслями о создании Logto MCP Server, включая:
MCP против Agent Skills: почему мы выбрали MCP
Проблемы, с которыми мы столкнулись при запуске MCP-сервера и как мы их решили
Как мы проектируем 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 не идеален. Большинство проблем связаны с незрелостью экосистемы. Со временем это улучшится. Пока мы используем обходные решения, чтобы покрыть реальные потребности.
В Agent Skills бизнес-логика и контекст заложены в один пакет. LLM знает, как ими пользоваться. MCP предоставляет только инструменты. После подключения LLM не знает:
Сценариев использования
Порядка вызовов
Бизнес-ограничений
В MCP есть концепция Instructions, но не все клиенты поддерживают её. К тому же, инструкции полностью загружаются в контекст при подключении, что тратит токены впустую.
Можно было бы добавлять объяснения в описание инструментов, но тут две проблемы:
Описания становятся сложными. Мультиинструментальные сценарии быстро запутываются и сложно поддерживать.
Чем больше инструментов — тем больше контекстное окно занимают описания.
Суть проста: если Instructions плохо поддерживаются — делаем их инструментом.
LLM может вызывать getInstructions по необходимости.
Для задачи А вызывается getTaskAInstructions. MCP-сервер возвращает подсказку, как выполнить задачу и как использовать другие инструменты.
Сложная бизнес-логика остаётся за инструкциями-инструментами. Остальные инструменты просты. Их описания касаются только их функций.
Похоже на Agent Skills: подсказки подгружаются по требованию. Это эффективнее глобальных Instructions, потому что ничего лишнего не грузится в контекст.
Во многих SaaS-продуктах нельзя раскрывать некоторые секреты (например, client secrets, API-ключи, ключи подписи webhook). Утечка даст возможность другим выдавать себя за тебя или получить прямой доступ к ресурсам.
Проблема LLM — чат не является безопасным каналом. Диалоги могут логироваться, копироваться, передаваться или попадать в логи отладки. Нельзя полагаться, что «только я и модель это видим». Передавать LLM долгоживущие секреты либо просить вывести их — большой риск.
Это типично и для традиционных веб-интеграций: разработчики часто берут секрет, кладут его в переменные окружения или конфиги, а затем инициализируют SDK.
Чтобы одновременно сделать онбординг простым и не жертвовать безопасностью:
Используем временные секреты на этапе интеграции
В процессе чата MCP-сервер отдаёт только кратковременные секреты (например, действительные 1 час). Их хватает, чтобы интеграция заработала, и к запуску в продакшн они обычно уже невалидны. Затем разработчик создаёт и подставляет production-секрет вне чата.
Явно ограничиваем границы безопасности
Мы явно предупреждаем: не создавайте, не вставляйте и не храните production-секреты в чате. Также напоминаем разработчикам, что даже переменные окружения или конфиги могут утечь, если агент/LLM может их читать через инструменты или косвенным доступом. Production-секреты должны храниться только там, где нет AI-интеграции.
Продакшн-секреты вне чата; направляем пользователя в консоль
Долгоживущие секреты не генерируются и не распространяются через чат. Их создают и управляют на странице консольных учётных данных. В чате мы только отправляем ссылку на консоль, чтобы пользователь дошёл до final setup сам.
В 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-сервер с read_file, write_file, а агенты сами их комбинируют.
Дополнительные принципы:
Держи логику и описания инструментов простыми во имя экономии контекста.
Для сложных сценариев используй инструменты getInstructions — грузим подсказки по запросу. Они тоже должны быть кратко описаны.
Иногда MCP-серверы должны давать не только инструменты, но и объяснения, как их комбинировать — как Agent Skills.
Это часто нужно в SaaS. Например — GitHub MCP Server, Logto MCP Server, различные аналитические платформы. Пользователь ждёт workflow, а не атомарные вызовы.
Инструмент getInstructions — костыль. Лучше, если бы поддержка закладывалась на уровне протокола.
Вызовы MCP-инструментов сильно расходуют контекст. Если обрабатывать их подпроцессами (sub-agent), основной диалог сможет получать только сжатые ответы.
