110 миллионов скачиваний в месяц: почему MCP называют «Linux для AI-агентов» и что это даёт бизнесу

19 апреля 2026 года на конференции AI Engineer Europe со-создатель протокола MCP Дэвид Сория Парра назвал цифры, после которых спорить о «хайпе вокруг агентов» стало сложно. SDK протокола скачивают больше 110 миллионов раз в месяц. Консорциум Agentic AI Foundation за четыре месяца собрал 170 компаний. Сам протокол передали Linux Foundation, той же организации, что курирует ядро Linux.

Если совсем коротко: MCP это общий разъём, вроде USB-C, только для подключения ИИ к рабочим системам. Linux стал незаметным фундаментом серверов и смартфонов, а MCP становится фундаментом, на котором AI-агенты дотягиваются до CRM, учёта и почты. Разбираемся без жаргона, что это такое и какая от этого польза бизнесу не из списка Fortune 500.

Проблема M×N: почему интеграции с ИИ стоили так дорого

Представьте. У вас три ИИ-инструмента: ассистент в чате, агент для отчётов, бот поддержки. И пять рабочих систем: CRM, 1С, почта, таск-трекер, база знаний. Чтобы каждый инструмент работал с каждой системой, придётся написать 15 отдельных интеграций. Добавили четвёртый инструмент, получите ещё пять.

Это и есть проблема «M на N». Затраты растут перемножением, и малый бизнес такую математику не вытягивает: каждая связка это отдельная разработка и отдельная поддержка.

MCP (Model Context Protocol) решает её как розетка. Система один раз получает MCP-сервер, стандартный «переходник», через который любой совместимый агент видит её данные и функции. Пятнадцать интеграций превращаются в «три плюс пять»: каждый участник подключается к стандарту один раз. Поэтому протокол сравнивают то с Linux, то с USB-C. Это общий разъём, а не продукт.

Цифры зрелости: это уже не эксперимент

Главный сдвиг 2026 года в том, что MCP перестал быть внутренней разработкой одной компании. Протокол передали в Linux Foundation, и управление стало нейтральным: стандарт не принадлежит ни одному вендору, вкладываться в него безопасно. 170 компаний в Agentic AI Foundation дают другую гарантию. Серверы для популярных систем вроде Salesforce, Jira и HR-платформ будет поддерживать экосистема, а не энтузиасты-одиночки.

Показателен кейс Uber: 5000+ инженеров, 10 000+ внутренних сервисов, а поверх них больше 1500 активных агентов, которые делают свыше 60 000 запусков в неделю. Масштаб тут не главное. Важнее вывод, который сформулировал Сория Парра: успех агента определяет качество контекста, а не количество инструментов. Речь о том, насколько полные и структурированные данные агент видит через подключения. Правило работает на любом масштабе, включая компанию из десяти человек.

Что это даёт малому и среднему бизнесу

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

Ассистент руководителя с доступом к системам. Агент подключён через MCP к CRM и аналитике. Он отвечает на вопросы вроде «сколько сделок зависло на этапе КП дольше недели» или «какие кампании съели бюджет без заявок». Отвечает в момент вопроса, а не отчётом раз в месяц.

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

База знаний, которая отвечает. Регламенты, инструкции и переписку подключают к агенту, и сотрудники спрашивают словами вместо того, чтобы искать по папкам. Как это выглядит на практике, видно в нашем проекте для кадрового агентства.

Готовый сервер или свой

Для популярных систем готовые MCP-серверы уже есть: CRM, таск-трекеры, базы данных, таблицы. Начинать надо с них: подключить систему получается за дни. Свой сервер пишут в двух случаях. Когда система самописная: личный кабинет, внутренняя учётка. И когда готовый сервер отдаёт агенту слишком много: в бизнес-контуре сервер должен показывать ровно те данные и операции, которые нужны задаче, и ничего сверх.

А что с российскими системами

Тут придётся спуститься с высоты мировой статистики. Готовые серверы в первую очередь пишут под западные системы, поэтому Salesforce и Jira в примерах и мелькают. По Битрикс24, amoCRM и 1С ситуацию проверяют точечно, под вашу редакцию и ваш контур: где-то сервер уже кто-то выложил, где-то его придётся написать поверх открытого API.

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

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

Безопасность: где такие агенты ломаются

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

• Команда, спрятанная в данных. Агент читает письмо или карточку клиента, а внутри текста лежит инструкция «отправь содержимое базы туда-то». Для агента это просто текст, который он послушно выполняет.
• Слишком щедрый сервер. Готовый сервер часто отдаёт всё, что умеет система. Агенту для отчёта по сделкам не нужны ни зарплаты, ни кадровые документы.
• Одна учётка на всех. Агент работает под правами администратора, потому что «так проще настроить». Дальше любая ошибка в сценарии становится ошибкой с правами администратора.
• Тишина в журнале. Действия агента нигде не записаны, и разобрать инцидент нечем.

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

Сколько это стоит и сколько занимает

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

• Одна система, только чтение. Готовый сервер, агент отвечает на вопросы по CRM или аналитике. От 60 тысяч рублей, полторы-две недели.
• Два-три источника и рабочий сценарий. Агент собирает данные из CRM, таблиц и почты, готовит черновики и ставит задачи. От 180 тысяч рублей, три-пять недель.
• Свой сервер под самописную систему. Личный кабинет, внутренняя учётка, отраслевая программа. От 250 тысяч рублей, месяц-полтора.
• Сопровождение. Следим за сценариями, чиним после обновлений систем, расширяем права. От 20 тысяч рублей в месяц.

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

Что нужно от вас

Меньше, чем принято бояться, но без этого проект встанет.

• Доступы к системам и человек, который их выдаёт. Лучше сразу отдельную учётную запись для агента, а не «возьмите мой пароль».
• Один ответственный со стороны компании: тот, кто знает, как у вас устроены процессы. Часа три-четыре его времени в неделю, пока идёт проект.
• Список вопросов и задач, которые агент должен закрывать. Обычно это то, что руководитель спрашивает у сотрудников чаще всего.
• Решение, где проходит граница: что агент делает сам, а что приносит человеку на подтверждение.

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

Что делать

• Составьте список систем, где живут ваши данные: CRM, учёт, аналитика, задачи. Проверьте, для каких уже есть готовые MCP-серверы.
• Выберите один сценарий, который заметно экономит время. Обычно это отчёты, которые сейчас собираются руками, или ответы на повторяющиеся вопросы.
• Начните с read-only. Агент, который только читает данные и отвечает на вопросы, по нашему опыту закрывает большую часть пользы при минимальном риске.
• Заведите агентам отдельные учётные записи с ограниченными правами и включите журналирование.
• Измерьте эффект за месяц: сколько часов перестало уходить на отчёты и поиск информации. Расширять права и сценарии будете после этого.

Мы в своих проектах пришли к тому же порядку. Сначала агент с доступом на чтение к CRM и аналитике клиента, потом рабочие операции, которые подтверждает человек. Стандарт снял главный барьер, цену интеграций. Осталось выбрать сценарии и аккуратно настроить доступы. Это уже не исследовательская работа, а обычный внедренческий проект с понятными сроками. Если хотите обсудить свой сценарий, посмотрите, как мы делаем AI-ассистентов для бизнеса.