Ещё недавно, если компания хотела подключить ИИ-ассистента к CRM, ERP или внутренней базе знаний, почти всегда приходилось строить интеграцию под конкретный продукт или платформу. Появление MCP — Model Context Protocol меняет эту модель: вместо того чтобы связывать каждую AI-систему с каждым корпоративным сервисом напрямую, взаимодействие с инструментами и данными можно вынести в отдельный слой.
Anthropic опубликовала MCP в ноябре 2024 года. В 2025-м поддержку протокола добавили OpenAI (в Agents SDK весной, в Responses API в мае), Google (в Gemini API и SDK в мае) и Microsoft (в Copilot Studio: предварительная версия в марте, общая доступность в мае). Собственный MCP-сервер развивает и «Битрикс24»: к нему можно подключать внешние AI-системы и работать через них с CRM и задачами.
В декабре 2025 года Anthropic передала MCP в Agentic AI Foundation под управлением Linux Foundation. Независимое управление протоколом и поддержка нескольких крупных компаний усиливают его шансы стать общим стандартом, но сами по себе не гарантируют внедрение в каждой организации.
Важно сразу очертить границы: MCP не заменяет REST API, webhooks, очереди сообщений или корпоративные интеграционные шины. Его задача другая, дать AI-агентам унифицированный способ взаимодействовать с корпоративными инструментами. Подробнее о том, как он сосуществует с остальным стеком, в конце статьи.
Проблема: AI-агентов становится больше
Представим обычную корпоративную инфраструктуру: CRM, ERP или WMS, база знаний, внутренние документы, сервисы аналитики, корпоративный чат и несколько AI-ассистентов для разных задач. Скажем, один помогает менеджеру по продажам, второй отвечает сотрудникам на вопросы по внутренним регламентам, третий анализирует данные склада. Каждому нужны доступ к данным и возможность выполнять определённые действия.
В простом варианте можно построить прямые интеграции: AI-ассистент → CRM, AI-ассистент → ERP, AI-ассистент → база знаний. Но как только AI-систем становится несколько, архитектура начинает быстро усложняться — возникает знакомая проблема N корпоративных систем × M AI-клиентов: при прямой схеме потенциально нужны связи между каждой системой и каждым клиентом. При общей реализации MCP интеграционный слой можно строить вокруг N серверов и M клиентов. Это упрощает повторное использование инструментов, хотя доступы и особенности систем всё равно требуют отдельной настройки.
Причём дело не только в количестве API. Разным AI-платформам приходится по-разному описывать инструменты, обрабатывать вызовы, авторизацию, ошибки и возвращаемые данные. Если компания меняет AI-платформу или добавляет нового агента, часть интеграционного слоя приходится адаптировать заново. MCP предлагает другой подход.
Что именно делает MCP
MCP это протокол взаимодействия AI-клиента с внешними инструментами и контекстом. Главная идея проста: корпоративная система не должна знать, какой именно AI-агент будет с ней работать. Вместо этого создаётся MCP-сервер, который предоставляет агенту набор разрешённых инструментов: получить карточку клиента, найти документ, проверить остаток товара, создать задачу, получить статус заказа, сформировать отчёт.
Архитектурно это выглядит так:
mermaid flowchart LR A[AI-агент] --> B[MCP-клиент] B --> C[MCP-сервер] C --> D[API компании] D --> E[(CRM / ERP / WMS)]
MCP-сервер обращается к уже существующим API корпоративной системы — переписывать CRM или ERP специально под MCP не нужно. По сути, MCP становится дополнительным интерфейсным слоем между AI и корпоративными инструментами, а не заменой того, что уже работает.
Как это выглядит на практике
Предположим, у компании есть CRM. Без MCP каждый новый AI-продукт означает отдельную интеграцию: ассистент №1 → CRM API, ассистент №2 → CRM API, агент №3 → CRM API. И каждый раз разработчикам приходится заново решать вопросы описания инструментов, авторизации и обработки ошибок.
С MCP можно сделать единый MCP-сервер для CRM, который предоставляет, например, get_customer, find_deal, create_task, update_deal. Разные AI-клиенты работают с одним и тем же набором инструментов через стандартизированный интерфейс:
mermaid flowchart LR A1[AI-ассистент продаж] --> M[MCP-сервер] A2[Корпоративный помощник] --> M A3[AI-агент поддержки] --> M M --> C[CRM API] C --> D[(CRM)]
Ценность здесь появляется именно на масштабе. Для подключения одной системы к одному ассистенту REST API справляется и без MCP выигрыш начинается, когда AI-клиентов становится несколько.
Если MCP-сервер использует общую учётную запись для вызова CRM API, CRM не увидит, какой сотрудник инициировал действие, пока сервер не передаст этот контекст отдельно. И здесь появляется важнейший корпоративный вопрос: кто имеет право выполнять конкретное действие?
MCP не решает проблему прав доступа автоматически
Спецификация MCP предусматривает авторизацию для удалённых серверов на базе OAuth, но сам протокол не определяет бизнес-права сотрудников в CRM или ERP. На демонстрации всё выглядит просто: «ИИ может посмотреть клиента и создать задачу». В реальной компании этого недостаточно. Один сотрудник имеет право только читать информацию о клиентах, другой создавать задачи, руководитель — менять сделки, а финансовый специалист — выполнять операции, которые влияют на деньги.
Поэтому недостаточно сказать: «MCP-сервер предоставляет инструмент update_order». Нужно определить, кто вызывает инструмент, от имени какого пользователя или агента, какие данные ему доступны, какие действия разрешены, какие требуют дополнительного подтверждения и что именно было изменено.
Условно права можно разложить по уровню риска:
| Действие | Уровень риска |
|---|---|
| Получить карточку клиента | Зависит от состава персональных данных |
| Найти внутренний документ | Зависит от уровня доступа к документу |
| Создать задачу | Средний |
| Изменить заказ | Высокий |
| Изменить остатки в ERP | Высокий |
| Провести финансовую операцию | Критический |
Отсюда практическое правило: MCP-сервер не должен автоматически публиковать AI-агенту все возможности корпоративного API. Лучше собрать отдельный контролируемый набор инструментов — например, из 200 API-методов ERP конкретному агенту доступны только пять. Это снижает потенциальный ущерб от ошибки агента, некорректного запроса или неправильно настроенных прав.
Есть и специфический риск: в письме, документе или карточке клиента могут оказаться скрытые инструкции, которые агент примет за команду (prompt injection). Нельзя считать содержимое таких источников доверенной инструкцией. Ограничение инструментов и подтверждение опасных действий человеком уменьшают последствия подобной атаки; сторонние MCP-серверы с доступом к корпоративным данным тоже требуют проверки.
От чтения к действиям
AI постепенно перестаёт быть только интерфейсом для поиска информации. На первом этапе ассистент отвечает на «Покажи остаток товара X» — это операция чтения. Следующий уровень: «Создай заявку на перемещение 50 единиц товара X» — а это уже изменение данных, и требования к безопасности здесь принципиально другие.
Для read-only операций достаточно одной модели контроля. Для write-операций могут потребоваться дополнительные разрешения, подтверждение пользователя, лимиты, двухэтапное выполнение, журналирование и возможность отката.
Практически это значит, что вместо автоматического выполнения команды «Перемести 500 единиц товара» система возвращает пользователю: «Будет создано перемещение 500 единиц со склада А на склад Б. Подтвердить?» — и только после подтверждения MCP-сервер вызывает соответствующий корпоративный API. Для финансовых, складских и кадровых систем такой шаг подтверждения — не перестраховка, а необходимость.
Аудит: кто на самом деле изменил данные
Для корпоративного AI недостаточно знать, что действие было выполнено. Нужно понимать, почему и кем оно было выполнено. Если AI-агент изменил сделку в CRM, в журнале желательно видеть всю цепочку:
mermaid flowchart LR U[Иван Петров] --> A[AI-агент] A --> T["MCP-инструмент update_deal"] T --> P[Проверка прав] P --> C[(CRM: статус изменён)]
Такой аудит позволяет разбирать спорные ситуации и расследовать ошибки. Для корпоративных систем это может оказаться даже важнее самого протокола интеграции: без восстановимой цепочки любое автоматическое изменение данных превращается в «кто-то что-то поменял, разбирайтесь».
Цена такого подхода
MCP не бесплатная абстракция, которую стоит добавлять в любую архитектуру. У неё есть четыре вполне конкретные статьи расходов.
Дополнительный инфраструктурный слой. Появляется ещё один компонент, который нужно развёртывать, мониторить, обновлять и защищать. Если MCP-сервер становится критическим элементом архитектуры, придётся считать его отказоустойчивость и доступность.
Задержка. Дополнительный сетевой вызов и обработка на MCP-сервере увеличивают время ответа. Для диалогового сценария это может быть приемлемо, а для процесса с жёсткими требованиями по времени задержку нужно измерять на реальной нагрузке.
Версионирование инструментов. Инструменты, доступные AI-агенту, становятся частью интеграционного контракта. Если сегодня агенту доступен create_order, а завтра параметры метода изменились, нужно думать о совместимости уже подключённых клиентов. MCP-слой требует такого же инженерного подхода к версиям, контрактам и тестированию, как обычный API. Развивается и сам протокол: спецификация выходит датированными ревизиями, поэтому при обновлении клиента и сервера нужно проверять их совместимость.
Наблюдаемость. Нужно понимать, какие инструменты вызываются чаще всего, какие запросы завершаются ошибкой, сколько времени занимает выполнение, какие агенты вызывают какие инструменты и какие операции изменяют данные. Без логирования и мониторинга MCP быстро превращается в дополнительную точку, которую сложно диагностировать.
Когда MCP имеет смысл, а когда избыточен
MCP интересен компаниям, у которых уже есть или планируется несколько AI-ассистентов, используются разные AI-платформы, AI нужно подключать к нескольким корпоративным системам, важно централизованно управлять доступом агентов к инструментам и хочется отделить AI-слой от внутренних API. Типичный сценарий: сегодня есть корпоративный чат-бот, а завтра появляются помощник для продаж, агент поддержки и ассистент для сотрудников — единый MCP-слой заметно упрощает архитектуру.
Если же сценарий проще, один AI-ассистент, одна корпоративная система, стабильный API и нет планов подключать других клиентов, — прямой вызов AI-ассистент → CRM API окажется проще, дешевле и быстрее, чем AI-ассистент → MCP → CRM API. Не стоит внедрять MCP только потому, что это новая технология: сначала нужно понять, какую архитектурную проблему она решает.
Где MCP стоит в общем интеграционном стеке
Теперь вернёмся к оговорке из начала статьи. MCP не заменяет REST, gRPC, webhooks, очереди сообщений или интеграционные платформы, у каждого механизма своя задача. REST используется для синхронного обмена между сервисами, webhooks — для передачи событий, Kafka или RabbitMQ — для асинхронного обмена и распределения сообщений. MCP отвечает за стандартизированное взаимодействие AI-клиентов с инструментами и контекстом. Подробнее о выборе REST, webhook и брокера — в соседней статье «REST, Webhook или Message Broker: что выбрать для интеграции корпоративных систем».
В реальной корпоративной архитектуре они существуют одновременно и на разных уровнях:
mermaid flowchart TB AI[AI-агент] --> MCP[MCP-сервер] MCP --> API[CRM API] API --> CRM[(CRM)] CRM -. события .-> K[Kafka / webhook] K --> S[Другие сервисы]
MCP в такой схеме не заменяет существующую архитектуру, а добавляет AI-интерфейс поверх неё.
Что может измениться в ближайшие годы
Главный потенциал MCP не в том, что компании смогут «подключить ChatGPT к CRM»: это можно было сделать и раньше. Потенциал в другом — AI-агенты постепенно становятся ещё одним типом корпоративных потребителей IT-систем, наряду с сотрудниками, мобильными приложениями и веб-интерфейсами. Если агентов действительно станет много, компаниям понадобится стандартный способ давать им доступ к корпоративным инструментам: человек работает через интерфейс, агент — через MCP, но обращаются они к одним и тем же системам.
Для корпоративного применения одного протокола при этом недостаточно. Вокруг него понадобятся единая модель идентификации, управление правами, аудит, мониторинг, контроль write-операций, версионирование инструментов и защита критичных действий. Именно эти элементы определят, насколько MCP окажется пригоден для реального enterprise-использования.
Вывод
MCP может стать общим слоем между AI-агентами и корпоративными инструментами, но не заменой существующих интеграций.
Если у компании один AI-сценарий и один API, прямая интеграция остаётся самым простым решением. Если же AI-клиентов становится несколько, появляются разные модели и агенты, а подключаемых систем всё больше, MCP решает проблему масштабирования интеграций. Такой слой нужно проектировать с учётом прав доступа, аудита, мониторинга и контроля действий.