MCP или GUI: как выбрать интерфейс для корпоративной операции

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

Ниже — учебный сценарий внутреннего service desk: сотрудник читает заявку, предлагает сменить исполнителя и передаёт изменение на подтверждение. Он не описывает готовую интеграцию конкретного продукта. Имена инструментов и полей придуманы для проектирования; перед внедрением их нужно реализовать и проверить в выбранной системе.

Разделите операцию на чтение, предложение и запись

В архитектуре MCP приложение-хост работает с серверами через клиентов; серверы предоставляют инструменты и другие возможности. Наличие tool с подходящим названием ещё не определяет бизнес-права пользователя.

Для примера выделим три действия:

Действие	Предпочтительный интерфейс для начала	Условие допуска
Найти доступную пользователю заявку	MCP и диалог	Сервер ограничивает выдачу правами пользователя
Предложить нового исполнителя	MCP для черновика; форма для сравнения	Предложение не изменяет запись
Подтвердить изменение	GUI либо проверенная форма MCP Apps	Видны точные поля; сервер повторно проверяет права и актуальность

Это проектная рекомендация для данного сценария. Обычный GUI тоже может скрывать существенные значения или обращаться к плохо защищённому backend. Оценивайте конкретный путь записи и доказательства его работы.

Предположим, в учебной заявке REQ-204 исполнитель team-a, а пользователь хочет назначить team-b. Диалог помогает найти нужный объект, но перед сохранением покажите идентификатор, старое значение, новое значение и последствия: будет ли отправлено уведомление, сменится ли доступ, запустится ли внешнее действие. Совпадения заголовков недостаточно для выбора объекта.

Подтверждение должно относиться к точному изменению

Предлагаемый внутренний объект подтверждения может выглядеть так:

{
  "ticket_id": "REQ-204",
  "expected_revision": "r17",
  "changes": {
    "assignee": {"from": "team-a", "to": "team-b"}
  },
  "mode": "proposal"
}

Это схема приложения, не стандарт MCP. Сервер должен сверить revision и разрешения при сохранении. Если заявка уже изменилась, предложенный вариант нужно показать заново. Кнопка «подтвердить» не должна незаметно применять другой diff.

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

Для повторов после timeout заранее определите поведение backend. Если ответ потерян, сначала запросите результат операции по сохранённому идентификатору. Слепой повтор может отправить уведомление дважды или повторить внешний эффект. Возможность вернуть старого исполнителя не означает, что все последствия изменения обратимы.

Когда подходит MCP Apps

MCP Apps позволяет серверному инструменту предоставить интерактивный UI внутри поддерживающего его клиента. Хост отображает такой интерфейс в sandboxed iframe. Это подходит для формы сравнения полей прямо в разговоре, если выбранные версии клиента и сервера поддерживают расширение.

В нашем сценарии форма может показывать заявку, proposed diff и две явные кнопки: применить или отменить. Серверная авторизация, проверка revision и журнал результата всё равно нужны. Sandbox iframe не заменяет права в service desk и не делает произвольный сервер доверенным.

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

Соберите пилот: модель через BetterToken, заявки через MCP

Для пилота можно взять Claude Desktop как клиент и подключить модель Claude через BetterToken по руководству настройки API. Используйте собственный API Key с доступом к провайдеру Claude и Gateway Base URL https://bettertoken.ai; точные поля и условия для вашей версии проверьте в руководстве. Сначала получите ответ на обычное короткое сообщение, чтобы отдельно проверить модельное подключение.

Затем подключайте тестовый MCP-сервер service desk средствами выбранного клиента и проверяйте доступ к одной несекретной заявке. BetterToken отвечает за модельный API-контур; учётные данные service desk, права пользователя и подтверждение записи настраиваются отдельно. Подключение модели не доказывает поддержку MCP Apps в конкретном режиме клиента — перед выбором встроенной формы проверьте её отдельно. Если форма недоступна, оставьте подтверждение в GUI.

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

Проверьте выбор на отказах

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

Проверка	Что должно произойти
Пользователь запрашивает чужую недоступную заявку	Сервер отказывает без раскрытия её содержимого
Читающая роль подтверждает смену исполнителя	Запись отклонена на сервере
Пользователь отменяет предложенный diff	Заявка остаётся прежней
После просмотра изменилась revision	Сохранение останавливается; нужен новый просмотр
Ответ после сохранения потерян	Статус выясняется до решения о повторе
Модель недоступна	GUI позволяет прочитать фактическое состояние
Форма используется с клавиатуры и screen reader	Можно понять изменение, подтвердить или отменить его

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

Оставьте след, по которому можно разобраться

Для данного сценария полезно записывать пользователя, ID заявки, согласованный diff, исходную revision, время, идентификатор операции и результат backend. Не сохраняйте в журнале tokens и полное содержимое закрытых заявок без необходимости. Политика хранения и доступа к журналу должна соответствовать правилам вашей организации.

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