spec v0.1
RU

Почему MCP-first

Почему MCP-first

UI-first-подход упирается в структурные ограничения — шесть тезисов о том, почему агентно-ориентированная архитектура возможностей является более последовательным ответом.

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

Агент не должен знать, на какой странице находится кнопка.

Основная проблема

Что на самом деле нужно агенту

Агент не навигирует по интерфейсам. Он вызывает возможности. Релевантные вопросы таковы:

  • Какие действия существуют?
  • Какие входные данные ожидает действие — какие выходные данные оно возвращает?
  • Какие права необходимы?
  • Какое действие рискованно или необратимо?
  • Когда нужно задать вопрос пользователю?
  • Что аудируется?

UI-first программное обеспечение не отвечает ни на один из этих вопросов. MCP-first — отвечает на все.

Klassisch

  1. Webapp
  2. Mobile App
  3. Admin UI
  4. API
  5. Automation
  6. AI-Integration

MCP-first

  1. Domain Model
  2. Action Layer
  3. Permission Layer
  4. MCP Tools
  5. MCP Resources
  6. MCP Workflows
  7. Audit Layer
  8. Webapp · Mobile · Admin · API · Automation

Тезис 1: AI-агенты используют ПО не так, как люди

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

Второй путь детерминирован, типизирован, с проверкой прав и аудируем. Первый создаёт хрупкую браузерную автоматизацию, которая ломается при каждом обновлении UI.

Пример: запланировать follow-up
  • schedule_follow_up(contactId, projectId, datetime, note)
  • contacts.search(query, tenantId)
  • reminders.create(contactId, datetime, note, assignedTo)
  • calendar.find_free_slot(participantIds, duration, after)

Тезис 2: Пользовательский интерфейс становится одним из многих клиентов

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

  • Человек через веб-приложение
  • Человек через мобильное приложение
  • AI-агент через MCP
  • Автоматизация через Worker
  • Сторонний провайдер через API
  • Внутренние системы через Events
  • CLI через Action Layer

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

Тезис 3: ПО без агентных возможностей трудно интегрировать

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

  • Браузерная автоматизация и парсинг экрана
  • Импорт CSV и ручные процессы копирования
  • Полуавтоматические рабочие процессы
  • Специальные решения для каждого клиента или интеграционного проекта

Эти обходные решения ломаются при изменениях UI, не масштабируются и не поддаются аудиту. MCP-first устраняет причину их существования, делая систему структурированно управляемой с самого начала.

Тезис 4: Лучший интерфейс для многих задач — никакой интерфейс

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

«Создай сводку всех открытых сделок.»
«С какими клиентами мне стоит связаться сегодня?»
«Проверь, не хватает ли документов у этого сотрудника.»
«Создай отчёт по всем проектам с рисками.»
«Сравни последние два расчёта зарплат.»

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

Low Сгенерировать сводку — Medium Создать документ — Critical Экспорт расчёта зарплат — эти различия система должна знать.

Тезис 5: MCP-first сокращает дублирование разработки

Если фича сначала реализуется как Action, каждый клиент может использовать её же — без двойной реализации:

create_project(name, templateId, ownerId, tenantId)

Это одно Action можно использовать из:

  • Веб-приложения
  • Мобильного приложения
  • Admin UI
  • MCP Agent
  • CLI
  • Worker
  • Процесса импорта
  • Интеграции
  • Тест-набора

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

Тезис 6: MCP-first принуждает к лучшей архитектуре

Кто строит MCP-first, вынужден автоматически моделировать чище. Каждая возможность требует:

  • чётких Domain Actions с однозначным намерением пользователя
  • типизированных схем входных и выходных данных
  • чётких прав и обработки ошибок
  • определённых побочных эффектов
  • Audit Events и уровней защиты

Это вынуждает чётко распределять ответственность предметной области до того, как будет написана хоть строчка UI-кода.

Пример: что должна описывать каждая возможность
  • Input Schema — типизированный, валидированный
  • Output Schema — детерминированный
  • Permission Scopes — какая роль может вызывать
  • Risk Level — low / medium / high / critical / forbidden
  • Side Effects — внешнее воздействие, да или нет
  • Audit Event — что логируется
  • Confirmation Policy — автономно или с разрешения человека

API-first был для разработчиков. MCP-first — для агентов.

API-first был для разработчиков.

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