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

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

Ниже — о том, почему привычный GUI может уступить место ИИ-агентам и как это решает вечную дилемму продуктового дизайна.

Надо упростить

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

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

В биллинге это особенно заметно. Человек редко приходит с задачей «Откройте мне раздел с прогнозом баланса по договору». Обычно он приходит с вопросом: «Денег хватит до конца месяца?»; «Почему доступный баланс меньше ожидаемого?»; «Что именно сейчас съедает бюджет?» или «Почему баланс так быстро уменьшается?».

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

Model Context Protocol (MCP) — это открытый протокол, который позволяет ИИ-моделям стандартным способом подключаться к внешним сервисам и данным. Если HTTP стал универсальным языком общения между приложениями, то MCP претендует на роль такого же универсального языка общения между ИИ и цифровыми продуктами.

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

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

Именно эту гипотезу я хочу обсудить.

Интерфейсы плохо масштабируются вместе с продуктом

У цифрового продукта обычно есть естественный жизненный цикл. Сначала появляется одна полезная фича. Для нее легко сделать понятный экран: одна таблица, несколько кнопок, пара фильтров.

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

Это не обязательно плохо. Для регулярной профессиональной работы хороший GUI незаменим. Бухгалтеру, инженеру, оператору поддержки или аналитику часто нужен именно предсказуемый рабочий экран: таблица, фильтры, массовые операции, история изменений, экспорт в CSV.

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

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

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

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

Агент меняет уровень абстракции

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

Не:

Открой раздел «Биллинг», выбери отчет, оцени баланс, найди прогноз, сравни несколько категорий услуг.

А:

Хватит ли мне денег до конца недели?

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

Чтобы ответить, агенту может понадобиться несколько действий:

1. получить баланс;

2. понять структуру балансов;

3. запросить прогноз потребления;

4. сопоставить потребления по услугам;

5. заметить риск отрицательного баланса;

6. объяснить результат человеческим языком;

7. при необходимости предложить следующее действие.

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

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

Конечно, здесь легко увлечься и начать обещать, что чат решит все проблемы UX. Не решит. Агент может неправильно понять запрос, выбрать не тот инструмент, быть слишком уверен в неполных данных, скрыть важные детали за красивым текстом. А в финансовых, инфраструктурных и административных продуктах цена такой ошибки слишком высока.

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

Почему MCP — не просто еще один API

На этом месте обычно возникает резонный вопрос: а чем это отличается от обычного API?

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

Но у API и MCP разные основные потребители. Обычный API чаще всего проектируется для разработчика, который заранее знает:

• какой endpoint ему нужен;

• какие параметры передать;

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

• как обработать ошибку;

• как интерпретировать ответ.

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

В спецификации MCP сервер может предоставлять не только инструменты, но и контекст, ресурсы и шаблоны взаимодействия. Сами инструменты могут быть найдены и вызваны моделью на основе описания и схемы входных данных. То есть MCP — это не просто HTTP-обертка над API.

Это слой, который делает возможности продукта доступными агенту в более декларативной форме.

Условно, API говорит: «Вот метод GET /v2/billing/prediction, вот параметры и формат ответа». А MCP говорит: «Я умею оценивать, на сколько хватит текущего баланса; вот какие данные мне нужны; вот какой структурированный результат я могу вернуть».

Разница может казаться косметической, пока инструментов мало.

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

При этом MCP не должен становиться заменой хорошо спроектированного API. Скорее это новый клиентский слой над ним — примерно как GUI, мобильное приложение или CLI, только рассчитанный на агентное взаимодействие.

Моя гипотеза

Моя рабочая гипотеза звучит так:

Через несколько лет большинство современных цифровых продуктов будут иметь MCP-сервер как основной способ взаимодействия с продуктом. Графический интерфейс останется, но станет одним из клиентов MCP, а не центральной точкой взаимодействия.

Это, вероятно, слишком смелая формулировка. И я не уверен, что она окажется верной в буквальном виде.

Сегодня продукт часто выглядит так:

Пользователь → GUI → бизнес-логика → данные

Возможная следующая модель:

Пользователь → агент → MCP → бизнес-логика → данные
                 ↓                ↑      
                GUI       →

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

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

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

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

Сейчас мы часто начинаем с вопроса: «Какой пользователь будет взаимодействовать с GUI?», но в агентной модели первым вопросом может стать другой: «Какие способности продукта должны быть доступны пользователю и как безопасно описать их агенту?».

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

Почему я решил проверить это на биллинге

Я решил не ограничиваться рассуждениями и собрать небольшой MCP-сервер для работы с биллингом Selectel.

Репозиторий проекта: mcp_selectel_billing.

Это не попытка сделать «новый интерфейс» и точно не продакшен-решение, которое я готов рекомендовать всем без оговорок. Это эксперимент.

В текущем пет-проекте есть несколько базовых возможностей:

• подключить аккаунт через сервисного пользователя;

• получить текущие балансы аккаунта;

• получить прогноз достаточности баланса и на сколько его хватит;

• пополнить баланс с сохраненной карты;

• создать ссылку на оплату новой картой;

• создать платеж через СБП;

• сформировать ссылку на платежное поручение (PDF);

• проверить статус платежа;

• получить отчет по услугам/расходам за период с фильтрами.

Сервер поддерживает подключение по Streamable HTTP и через stdio, поэтому его можно использовать с разными агентами и MCP-клиентами. 

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

В GUI все это обычно раскладывается на экраны, таблицы, поля и подсказки. В агентном интерфейсе пользователь может просто спросить: «Проверь мой баланс в Selectel и скажи, есть ли риск блокировки в ближайшие дни.» А дальше агент сам выбирает последовательность действий.

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

Реальные кейсы

Я работаю с Hermes agent через Telegram. Это удобный open-source фреймворк для запуска ИИ-агентов, в нем есть интеграция с мессенджерами и MCP. Связка MCP-сервера и LLM здесь через в обычный чат, так что вместо того чтобы кликать по вкладкам, я просто пишу боту задачи текстом.Это удобный open-source фреймворк для запуска ИИ-агентов, в нем есть интеграция с мессенджерами и MCP. Связка MCP-сервера и LLM здесь через обычный чат, так что вместо того чтобы кликать по вкладкам, я просто пишу боту задачи текстом или голосовым сообщением.

Отслеживание баланса и проактивные действия 

Агент сам понимает контекст, проверяет текущий баланс, видит разделение на основной и бонусный счета, а затем самостоятельно весит регулярную фоновую задачу (cronjob). Система не просто пришлет уведомление, а сама выполнит рутинную работу по подготовке платежки.

Агент сам понимает контекст, проверяет текущий баланс, видит разделение на основной и бонусный счета, создает регулярную задачу (cronjob). Система не просто пришлет уведомление, а сама выполнит рутинную работу по подготовке платежки.

Инфографика расходов

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

На графике автоматически группируются общие расходы, средний темп трат в день, главный драйвер расходов, динамика по месяцам и детальная структура по метрикам: диски SSD, RAM, vCPU и публичные IP.

Пополнение баланса

Агент мгновенно вызывает метод mcp_selectel_top_up_balance_saved_card, проводит платеж и возвращает статус «Готово» с подтверждением суммы и маскированным номером карты, с которой произошло списание.

Первые выводы

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

Хороший MCP-сервер начинается не с протокола

Самая сложная часть — выделить действительно полезные продуктовые способности. Например, «получить баланс» — это техническая операция. А «оценить риск нехватки средств и объяснить, что влияет на ситуацию» — уже полезная пользовательская способность.

Если просто механически завернуть каждый endpoint API в MCP-tool, получится каталог методов. Агенту будет сложно выбирать между ними, а пользователю не станет заметно проще.

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

Агенту нужны не только действия, но и контекст

Инструмента недостаточно, если агент не понимает терминологию продукта.

Что такое «доступный баланс»? Чем он отличается от задолженности? Какие категории услуг критичны? Что означают разные режимы оплаты? Какие действия допустимы, а какие требуют подтверждения?

Часть этого можно передать в описаниях инструментов. Часть — через ресурсы и документацию. Часть — через системные инструкции агента.

Но это означает, что MCP-сервер — не просто прокси к API. Это еще и слой продуктовой семантики.

Безопасность становится частью UX

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

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

Нужны:

• минимально необходимые права;

• явное подтверждение чувствительных операций;

• понятное отображение того, что агент собирается сделать;

• аудит вызовов;

• ограничения на комбинации опасных действий;

• защита от подмены контекста и prompt injection.

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

GUI не исчезнет

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

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

Что пока вызывает у меня больше вопросов, чем ответов

Я не считаю, что MCP уже решил проблему взаимодействия человека с продуктом. Скорее, он сделал эту проблему интереснее.

У меня пока остаются несколько ключевых вопросов:

• Как проектировать MCP-инструменты так, чтобы они не превращались в копию REST API?

• Как безопасно давать агентам доступ к критичным операциям и данным?

• Как объяснять пользователю, что именно сделал агент и почему он принял такое решение?

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

Станет ли MCP стандартным способом взаимодействия агентов с цифровыми продуктами — или останется нишевой технологией для разработчиков?

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

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