Что такое MCP (Model Context Protocol) и зачем он бизнесу: AI-агенты + CRM простыми словами

Как только вы пытаетесь “подключить” её к CRM и рабочим системам, начинается зоопарк интеграций: один коннектор для базы знаний, второй для CRM, третий для файлов, четвёртый для задач. Всё это ломается, версионируется, требует прав доступа и логирования.

MCP (Model Context Protocol) появился как попытка навести порядок: сделать единый, стандартизированный способ “подключать” AI-приложения и AI-агентов к данным и действиям в ваших системах (CRM, базы, файловые хранилища, сервис-деск, BI и т.д.).

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

MCP в одном абзаце

MCP — это открытый стандарт для связи “AI-клиента” (например, рабочего ассистента или агента) с “MCP-сервером”, который представляет внешнюю систему: CRM, базу знаний, диск, таск-трекер. Общение идёт сообщениями JSON-RPC, а подключение может быть локальным (stdio) или удалённым (Streamable HTTP).

Если упростить: MCP — это договорённость, как именно агент запрашивает “дай мне список сделок”, “создай задачу”, “найди документ”, “обнови стадию”, и как система отвечает так, чтобы агент мог действовать, а не гадать.

Почему MCP вообще понадобился

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

MCP пытается вынести “подключение к миру” в отдельный слой. Вы один раз делаете сервер, который знает вашу CRM и вашу политику доступа, а дальше разные клиенты (агенты) подключаются к нему по общему протоколу.

Как устроен MCP: три роли

В официальной терминологии есть “host”, “client” и “server”.

Host — это среда, где живёт ассистент (например, десктоп-приложение или платформа для агентов). Она поднимает подключения к серверам.

Client — это “логика общения” с конкретным MCP-сервером: отдельное соединение на сервер.

Server — это адаптер к внешней системе: CRM, диск, база знаний. Он публикует набор “инструментов” (actions) и “ресурсов” (data).

Важно для бизнеса: сервер — это место, где вы реально контролируете доступы и безопасность. И это же место, которое можно поставить “рядом с CRM”, чтобы не раздавать токены куда попало.

Как выглядит “AI-агент + CRM” на MCP на примере

Сценарий из жизни отдела продаж.

Менеджер пишет ассистенту:
“Посмотри все сделки в стадии ‘КП отправлено’ старше 7 дней. Где нет задачи на повторный контакт — создай. По каждой сделке дай короткое резюме: кто клиент, что предлагали, что стопорит.”

Если CRM подключена через MCP-сервер, агент делает примерно следующее:

1. Запрашивает у MCP-сервера инструмент “получить сделки по фильтру”.
2. Получает структурированный список сделок (не скриншот и не “на глаз”).
3. Для каждой сделки запрашивает “история/заметки/последний контакт”.
4. Если нет задачи — вызывает инструмент “создать задачу” и привязывает к сделке.
5. Возвращает менеджеру сводку и список созданных задач.

Ключевое отличие от “чатика”: агент не придумывает. Он читает и действует через инструменты, которые вы ему дали.

Зачем MCP бизнесу, если “и так есть Make/Albato”

iPaaS-интеграции (Make, Albato и подобные) решают задачу “система А отправляет событие в систему Б”. Это полезно и останется полезным.

MCP закрывает другую щель: “ассистент/агент должен уметь сам выбрать действие в процессе разговора”. То есть не заранее прописанный сценарий, а динамика: человек задаёт задачу, агент понимает, какие инструменты доступны, и выполняет цепочку действий.

Для бизнеса это обычно выливается в 4 практичные вещи:

Первое: меньше “ручных мостиков” под каждого агента. Если завтра вы меняете агент-платформу, MCP-сервер (как слой к CRM) может остаться тем же.

Второе: управляемость. Инструменты можно ограничивать, логировать, версионировать, отключать. Это больше похоже на нормальную эксплуатацию, чем на “прикрутили плагин к чату”.

Третье: скорость экспериментов. Один и тот же сервер можно подключить к разным ассистентам и сравнить, кто реально помогает отделу продаж, а кто делает красивую имитацию.

Четвёртое: единая модель доступа к данным. Не “каждому боту — свой токен”, а один контролируемый шлюз.

MCP уже не “теория”: где он встречается в реальном мире

1. Anthropic описывает MCP как открытый стандарт для “безопасных двусторонних подключений” AI-инструментов к данным и системам.
2. Microsoft добавил поддержку MCP в Copilot Studio, сначала как релиз, затем объявлял general availability. То есть MCP начинает жить не только в “хакерских” демках, а в корпоративных платформах для агентов.
3. В экосистеме MCP есть репозиторий с референс-серверами и каталогом серверов. Это сигнал, что стандарт “обрастает” готовыми коннекторами.
4. Для российской реальности важная деталь: у Битрикс24 есть публичная документация про “MCP server для работы с REST API”, то есть тема уже дошла до массовой CRM-экосистемы.
   По amoCRM/Kommo уже есть сторонние MCP-серверы (как минимум в виде open-source проектов).
   Плюс крупные облака публикуют “шаблоны MCP-серверов” под популярные системы, включая amoCRM.

Что MCP не решает (и где обычно обманываются ожидания)

MCP не превращает хаос в порядок сам по себе.

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

Если у вас нет понятных правил доступа (кто может видеть выручку, кто может выгружать контакты, кто может писать в сделки), MCP тоже не спасёт. Он лишь даёт удобный канал к данным и действиям.

И ещё: MCP не гарантирует “умность” агента. Он даёт агенту инструменты. Как агент ими пользуется — вопрос качества промпта, модели, ограничений и тестирования.

Безопасность: главная цена “агентов с доступом к CRM”

Как только вы даёте модели инструменты “создать сделку”, “изменить контакты”, “отправить сообщение”, вы переходите из режима “текст в чате” в режим “операции в бизнес-системах”. Здесь рисков больше, чем кажется.

Самый обсуждаемый класс рисков — prompt injection, в том числе “косвенная” (indirect): когда вредная инструкция приезжает не от пользователя, а из данных, которые агент читает (например, из письма, документа, карточки лида). Microsoft отдельно писал про подходы к защите от таких атак в контексте MCP.

Вторая зона риска — supply chain и качество сторонних серверов/пакетов. Были кейсы, когда у стороннего “моста” к MCP находили уязвимость уровня command injection, что потенциально ведёт к удалённому выполнению команд.

Практичный вывод для бизнеса: MCP-сервер — это не “плагин, который ставим менеджерам”. Это компонент интеграционной инфраструктуры. Его нужно сопровождать примерно как интеграцию CRM с телефонией или биллингом.

Как начать с MCP без “большого внедрения”

Если цель — статья для бизнеса, то честный ответ такой: начинать стоит не с “протокола”, а с задачи.

Рабочий пилот обычно выглядит так:

1. Выбираете один узкий сценарий, где ошибка не убивает бизнес. Например: “сводка по сделкам недели” или “создание задач на фоллоу-ап”, но без права удалять/массово править данные.
2. Делаете минимальный набор инструментов на MCP-сервере: чтение списка сделок + создание задачи + чтение заметок. Чем меньше инструментов, тем проще контролировать.
3. Включаете логирование: кто вызвал инструмент, какие параметры, какой результат. Без этого агент превращается в “чёрный ящик”.
4. Прогоняете сценарий на тестовой копии данных (или на ограниченной выборке).
5. Подключаете отладку. У MCP есть инструменты вроде MCP Inspector для тестирования серверов и поведения.

Через 1–2 недели такого пилота становится ясно, это полезно именно вашей команде или это очередная игрушка.

FAQ — вопросы и ответы про MCP