Как мы создали MCP для NutriFit и открыли платформу для AI-ассистентов

Искусственный интеллект постепенно меняет сам способ взаимодействия с программным обеспечением. Еще недавно пользователь открывал приложение, переходил между разделами, применял фильтры, искал нужные показатели и вручную собирал информацию из нескольких экранов. Теперь все чаще ту же задачу можно сформулировать обычным языком.

«Покажи, как менялся мой вес за последние три месяца».

«Найди мои последние лабораторные результаты».

«Сравни потребление белка за эту и прошлую неделю».

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

Для NutriFit таким слоем стал Model Context Protocol — MCP.

Мы создали собственный MCP-сервер, который позволяет совместимым AI-клиентам работать с NutriFit напрямую: получать разрешенные пользователем данные, выбирать необходимые инструменты и выполнять предусмотренные платформой действия.

У NutriFit уже существовал полноценный backend и API. Через него работают веб-приложение и внутренние сервисы платформы.

Поэтому технически задача заключалась не в создании еще одного API.

Проблема была другой.

Обычный API проектируется прежде всего для разработчика. Разработчик знает документацию, понимает назначение endpoint'ов, последовательность запросов, структуру параметров и бизнес-логику приложения.

AI-модель работает иначе.

Она должна сама определить:

MCP позволяет описать функции приложения как набор структурированных инструментов, доступных AI-клиенту.

В результате NutriFit становится для модели не набором неизвестных HTTP-endpoint'ов, а системой понятных действий.

Например, запрос пользователя:

«Покажи мои последние измерения тела»

может быть преобразован AI-клиентом в вызов соответствующего инструмента NutriFit, после чего модель получает структурированный результат и уже формирует удобный человеку ответ.

Пользователю при этом не нужно знать название метода, структуру базы данных или устройство API.

Model Context Protocol развивается как открытый стандарт взаимодействия AI-приложений с внешними данными и инструментами. Его идея состоит в том, чтобы отделить модель от конкретной реализации каждого внешнего сервиса.

Вместо индивидуальной интеграции NutriFit с каждым AI-продуктом мы можем реализовать стандартный MCP-интерфейс, а совместимый клиент уже самостоятельно обнаруживает доступные инструменты и понимает их схемы.

Это особенно важно для независимого SaaS-продукта.

Мы не хотели строить интеграцию, жестко привязанную к одной нейросети или одному пользовательскому интерфейсу. NutriFit должен оставаться самостоятельной платформой, а AI — еще одним способом взаимодействия с ней.

Сегодня MCP уже используется как основа интеграции внешних инструментов и данных с AI-приложениями. Например, OpenAI строит поддержку собственных приложений и custom apps в ChatGPT на базе MCP, включая возможность чтения данных и, в поддерживаемых сценариях, выполнения действий записи и изменения.

Сам протокол продолжает активно развиваться: актуальная спецификация MCP от 28 июля 2026 года расширила возможности маршрутизации, авторизации, кеширования каталогов инструментов и масштабирования MCP-серверов.

Для нас это означает важную вещь: мы интегрируем NutriFit не с конкретным интерфейсом AI, а с формирующейся инфраструктурой AI-приложений.

Одна из самых больших ошибок при создании MCP — механически превратить каждый backend endpoint в отдельный инструмент.

Мы пошли от пользовательских сценариев.

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

Поэтому сначала мы разделили возможности MCP на логические группы.

AI должен уметь получать данные пользователя:

Для консультантов появляется второй уровень сценариев — работа с клиентами, которым они имеют право помогать внутри NutriFit.

Здесь особенно важно разграничение доступа: наличие инструмента в MCP не означает, что через него можно получить данные любого пользователя системы.

Авторизация и права NutriFit продолжают действовать независимо от того, какой AI-клиент инициировал запрос.

На этапе, описанном в этой статье, MCP-интерфейс NutriFit вырос до 71 инструмента.

Но само количество никогда не было нашей целью.

Гораздо сложнее оказалось добиться того, чтобы AI действительно правильно выбирал между ними.

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

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

Для каждого инструмента необходимо было понятно определить:

Что он делает.Описание должно позволять модели отличить его от соседних инструментов.

Когда его следует использовать.Модель должна понимать пользовательское намерение, которое соответствует этому действию.

Какие параметры необходимы.Аргументы должны иметь однозначные имена, типы и ограничения.

Что возвращается в результате.AI-клиенту желательно получать структурированные данные, а не текст, предназначенный только для отображения человеку.

Что инструмент не делает.Иногда границы возможностей оказываются не менее важными, чем само описание функции.

Мы многократно тестировали инструменты естественными запросами, намеренно формулируя одну и ту же задачу по-разному. Пользователь ведь не будет писать название метода. Он напишет: «Что я ел вчера?» или «Покажи мои приемы пищи за вчерашний день» или просто: «Вчерашнее питание».

Во всех трех случаях AI должен самостоятельно понять намерение и выбрать правильный путь к данным.

Одним из ключевых требований стала работа с авторизацией.

Наш MCP-сервер доступен удаленно, а подключение пользователя выполняется через OAuth. Пользователь входит в свою учетную запись NutriFit и предоставляет клиентскому приложению соответствующий доступ.

Это принципиально важно.

MCP не должен превращаться в обход существующей системы безопасности приложения.

AI получает не «доступ к NutriFit», а возможность выполнять определенные действия от имени конкретного авторизованного пользователя и в пределах его прав.

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

Таким образом, источником истины о правах доступа остается NutriFit.

AI-клиент решает, какой инструмент вызвать. Но MCP-сервер и backend решают, имеет ли пользователь право выполнить этот запрос.

Для NutriFit этот принцип особенно важен, потому что часть информации относится к здоровью человека.

NutriFit хранит и структурирует данные. Например, система может предоставить AI историю лабораторных показателей, измерений тела, питания или активности.

Но факт наличия этих данных не означает, что MCP превращает NutriFit в систему постановки медицинских диагнозов.

Если пользователь спрашивает:

«Покажи мои последние лабораторные результаты», — NutriFit может предоставить соответствующие записи.

Если затем пользователь спрашивает AI:

«Что могут означать эти показатели?», — дальнейшее объяснение уже формируется самим AI-приложением в соответствии с его собственными правилами, возможностями и ограничениями.

Такое разделение позволяет не смешивать две принципиально разные функции:

NutriFit как источник структурированных пользовательских данных и AI-систему как слой анализа и взаимодействия с человеком. Этот принцип мы старались сохранить во всем MCP-интерфейсе.

Самый очевидный сценарий MCP — чтение данных.

Пользователь задает вопрос, AI получает данные из NutriFit и объясняет их.

Но значительно интереснее становится тогда, когда AI способен не только читать информацию, но и выполнять разрешенные действия.

Например, пользователь может попросить AI внести изменение в профиль или выполнить другое действие, которое NutriFit предоставляет через MCP.

Здесь требования к проектированию значительно выше.

Есть большая разница между запросами: «Покажи мои цели» и «Измени мою цель». Первый запрос читает существующие данные. Второй изменяет состояние системы.

Поэтому write-инструменты необходимо проектировать так, чтобы намерение пользователя было максимально прозрачным, параметры — однозначными, а потенциально значимые действия можно было отделить от обычного получения информации.

Современная реализация MCP в ChatGPT также различает подобные сценарии: для write/modify действий клиент может запрашивать у пользователя дополнительное подтверждение в зависимости от разрешений и контекста операции.

Так появляется гораздо более интересная модель взаимодействия.

AI перестает быть только интерфейсом поиска информации и постепенно становится интерфейсом управления приложением.

Особенно хорошо преимущество MCP заметно в запросах, затрагивающих сразу несколько частей NutriFit.

В классическом интерфейсе пользователь мог бы:

При работе через AI тот же сценарий может начинаться одной фразой:

«Посмотри, как менялись мой вес, питание и активность за последний месяц, и кратко подведи итоги».

AI может определить, какие данные ему необходимы, вызвать несколько независимых инструментов NutriFit, объединить результаты и представить их в одном контексте.

Именно здесь становится заметно фундаментальное отличие AI-интерфейса от обычного UI.

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

Технически поднять MCP endpoint — только начало работы.

Основное время заняли детали, которые становятся заметны только во время реального взаимодействия модели с системой.

Насколько точно описан инструмент?

Не перепутает ли AI два похожих действия?

Достаточно ли данных возвращается для ответа?

Не возвращаем ли мы, наоборот, лишнюю информацию?

Корректно ли AI воспринимает даты и единицы измерения?

Понимает ли разницу между данными NutriFit и собственным выводом?

Что произойдет, если пользователь попросит выполнить действие, выходящее за пределы возможностей платформы?

Что произойдет при отсутствии данных?

Что произойдет при недостаточных правах?

Что произойдет при попытке изменить данные без однозначного намерения пользователя?

Поэтому значительная часть разработки превратилась в последовательность:

описание → тестовый запрос → вызов инструмента → анализ поведения → корректировка схемы → повторный тест.

Для MCP качество интерфейса определяется не только тем, отвечает ли сервер на запрос. Настоящий критерий — способен ли AI стабильно пользоваться этим интерфейсом без знания внутреннего устройства NutriFit.

Отдельной частью работы стали проверки граничных случаев.

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

Гораздо больше информации дают неправильные, неоднозначные и потенциально опасные запросы.

Мы проверяли, как система ведет себя, когда пользователь:

Такие тесты помогли провести более четкую границу между тремя участниками процесса:

NutriFit, который предоставляет данные и инструменты;

AI-клиентом, который выбирает инструменты и формирует ответ;

пользователем, который определяет цель взаимодействия и предоставляет необходимые разрешения.

Сегодня MCP превращает NutriFit в платформу, с которой можно взаимодействовать не только через традиционный пользовательский интерфейс.

Совместимый AI-клиент может обнаружить доступные возможности NutriFit и использовать их в соответствии с запросом пользователя.

Вместо: приложение → раздел → фильтр → запись → график

появляется другой путь: намерение → AI → нужные инструменты NutriFit → результат.

При этом классический интерфейс никуда не исчезает. Он остается необходимым для подробной работы с данными, визуализации, настройки и специализированных рабочих процессов.

AI добавляет еще один слой — возможность обращаться к системе на человеческом языке и объединять несколько функций приложения вокруг одной задачи.

Для нас MCP — не отдельная экспериментальная функция и не способ добавить модное слово «AI» в описание продукта.

Это архитектурное направление развития NutriFit.

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

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

Именно поэтому мы решили сделать MCP частью инфраструктуры NutriFit уже сейчас.

Мы не знаем, какой интерфейс для работы с AI станет доминирующим через несколько лет. Это может быть ChatGPT, Claude, специализированный профессиональный ассистент или продукт, которого сегодня еще не существует.

Но если он понимает открытый протокол и способен работать с инструментами NutriFit, нам не требуется заново изобретать интеграцию для каждого нового интерфейса.

Для нас в этом и заключается главная идея MCP: данные остаются в NutriFit, бизнес-логика остается в NutriFit, права доступа остаются в NutriFit — но способ взаимодействия с платформой больше не ограничивается интерфейсом самого NutriFit.

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