Автор: Александр Балаш (CEO & Chief System Architect, dlab.md) | Март 2026
Должен кое в чём признаться. Три месяца назад один из наших Python-скриптов подключался к ERP с отключённой проверкой SSL. verify=False, прямо в коде. Скрипт, который управлял опубликованным контентом на боевом сайте. Я обнаружил это во вторник, во время код-ревью, которое откладывал три недели.
Тот скрипт был одним из шести. У каждого — свой способ аутентификации в Odoo. Каждый тихо делал свою работу. Каждый был маленькой технической бомбой.
Мы удалили все шесть. Заменили одним MCP-сервером. Никто не заметил — потому что всё просто продолжило работать. Только лучше, предсказуемее и без лишних рисков безопасности.
Эта статья — о той миграции, о том, почему 957 приложений в средней компании уже плохо уживаются с самодельными point-to-point интеграциями, и о том, что приходит им на смену. И не менее важно — о том, когда повторять наш путь точно не стоит.
Мы удалили 6 скриптов — и никто не заметил
Вот с чем мы жили в феврале 2026: шесть Python-скриптов, написанных за полтора года разными людьми в разное время. Каждый решал одну и ту же задачу немного по-своему — как загрузить данные в Odoo 18 и как потом их оттуда забрать.
Скрипт №1 публиковал статьи в блоге. Скрипт №2 управлял SEO-метаданными. Скрипт №3 загружал обложки. Скрипт №4 запускал аудиты контента. Картина понятна. Все подключались к Odoo через XML-RPC. И каждый заново изобретал аутентификацию, обработку ошибок и — в одном особенно неприятном случае — проверку SSL-сертификатов.
Проблема была не в том, что они не работали. Работали. Проблема была в другом:
- Шесть отдельных поверхностей атаки. Отдельные credentials, отдельные точки отказа, отдельные ошибки конфигурации. Один
verify=False— и у вас уже не архитектура, а исключение из базовой гигиены безопасности. - Нулевая совместимость с AI. Когда мы начали подключать AI-агентов к контентным операциям, ни один из этих скриптов не был для них обнаружим. Агент не может вызвать то, о существовании чего он не знает.
- Мультипликация поддержки. Odoo меняет поведение API — обновляй шесть скриптов. Добавляешь новый язык — обновляй шесть скриптов. Хочешь
dry_run— внедряй его везде вручную.
Миграция на MCP заняла две недели. Вот что изменилось:
| Метрика | До (6 скриптов) | После (1 MCP-сервер) |
|---|---|---|
| Единиц кода | 6 отдельных файлов | 1 единый сервер |
| Реализаций аутентификации | 6, каждая вручную | 1, централизованная через env |
| SSL-костыли | 1 (verify=False) | 0, нормальная цепочка сертификатов |
| Совместимость с AI | Нулевая | Нативное обнаружение инструментов |
Возможность dry_run | 0 из 6 | 11 из 11 инструментов |
| Аудит контента | Вручную, по одной статье | Автоматизировано, 27 статей за <3 секунды |
| SEO-аудит | Не существовал | Schema.org + валидация мета по всем статьям |
Что удивило больше всего: никто в команде не спросил, куда делись старые скрипты. MCP-сервер делал всё то же самое — плюс аудит контента, SEO-валидацию, управление pSEO-страницами и прямые операции с записями Odoo — через единый интерфейс.
Если ваша интеграционная инфраструктура выглядит похоже, корневая проблема обычно не в протоколе как таковом, а в управлении. Мы разбирали это с точки зрения Zero-Trust в статье Zero-Trust IT Audit: Как обезопасить бизнес-процессы перед выходом на рынки Европы. MCP помог сократить число движущихся частей, но реальный выигрыш пришёл от единой точки контроля, логирования и отката.
Полная картина: 4 сервера, 87+ инструментов
Теперь стоит отойти на шаг назад. Когда люди слышат «мы построили MCP-сервер для блога», они часто думают, что речь о нишевом workflow. На практике это была только одна миграция из четырёх.
Вот наша MCP-инфраструктура в продакшене на март 2026:
| MCP-сервер | Инструменты | Что делает |
|---|---|---|
dlab-mcp | 11 | Публикация блога, SEO-аудиты, генерация pSEO-страниц, CRUD записей Odoo |
ql-mcp | 60+ | Управление RSOC-доменами, создание кампаний, исследование ключевых слов, отчётность по доходам |
rsoc-bot | 10+ | Отчёты P&L, SQL-запросы к боевой БД, прогнозирование на Prophet, алерты мониторинга |
telegram | 6 | Доставка алертов, форматированные отчёты, очередь команд, управление пользователями |
Итого: 4 боевых MCP-сервера, 87+ инструментов, которыми ежедневно пользуются AI-агенты. Каждая операция записи по умолчанию идёт с dry_run=True. Каждый вызов логируется. Агент получает реестр инструментов в момент подключения — без Swagger-файлов, без отдельной документации для каждого сценария.
Команда из двух инженеров управляет всем этим. Здесь важен не масштаб ради масштаба, а рычаг: меньше разрозненного кода, меньше ручной поддержки, меньше скрытых исключений.
[ AI-Агент ]
|
+-----------------+-----------------+
| | |
(MCP) (MCP) (MCP)
| | |
[ dlab-mcp ] [ ql-mcp ] [ rsoc-bot ]
| | |
[ Odoo 18 ] [ Lead-Платформа ] [ PostgreSQL ]
|
(MCP)
|
[ telegram ]
|
[ Telegram API ]Рис. 1: MCP-инфраструктура dlab.md — 4 сервера, 87+ инструментов. Каждый сервер оборачивает бизнес-бэкенд за стандартизированным интерфейсом.
Почему REST для этого не создавался
Здесь важно быть точным, потому что вокруг темы уже слишком много лозунгов.
REST был сформулирован Роем Филдингом в 2000 году и решал реальную инженерную задачу: давал разработчикам предсказуемый способ строить интеграции. Stateless-запросы, единый интерфейс, ресурсо-ориентированный дизайн — всё это было и остаётся разумным выбором для большого класса систем.
Но у REST есть ограничение, которое стало особенно заметно в 2025–2026 годах: его основной потребитель — человек-разработчик или классический сервис-клиент. Не AI-агент, которому нужно самостоятельно обнаруживать доступные действия, понимать схемы параметров, сохранять контекст и оркестрировать многошаговые процессы.
Вот где начинаются структурные расхождения:
| Решение REST | Почему это ломается для AI |
|---|---|
| Stateless | AI-агентам нужен контекст между вызовами. В REST это состояние приходится собирать снаружи, а значит вы строите ещё один слой логики. |
| Нет нативного обнаружения | Агент не должен «читать документацию как человек». Ему нужны машинно-читаемые описания инструментов и параметров. |
| Только запрос-ответ | Для длинных операций нужны прогресс, частичные результаты, отмена и иногда двусторонний streaming. |
| Документация для людей | Swagger и OpenAPI полезны инженерам, но AI лучше работает с типизированными схемами и короткими описаниями действия. |
| Custom-код на каждую интеграцию | Каждый API тянет за собой отдельный клиент, отдельные ошибки, отдельные ретраи. В enterprise-среде это быстро становится центром затрат. |
MCP закрывает эти пробелы: даёт сессии с состоянием, нативное обнаружение инструментов, JSON-RPC 2.0, типизированные схемы и единый контракт между агентом и сервером.
Но здесь важна оговорка. Это не означает, что REST устарел или стал бесполезен. Это означает, что REST всё чаще перестаёт быть хорошим верхнеуровневым контрактом оркестрации для AI-сценариев.
Если вы работаете с PII, финансовыми данными или трансграничной обработкой, переход на MCP нельзя рассматривать отдельно от модели безопасности. На практике это означает Zero-Trust, scoping прав, аудит вызовов, rollback-процедуры и сегментацию доступа. По этой теме полезно дополнить чтение статьёй Data Protection by Design: Почему ваши скрипты автоматизации обходятся в €20 миллионов.
MCP против альтернатив: честное сравнение
Если смотреть на это как инженер, следующий вопрос вполне логичен: почему именно MCP? Почему не A2A от Google, не LangChain Tools, не автогенерация инструментов из OpenAPI?
Справедливый вопрос. Вот наша оценка, основанная на продакшен-опыте:
| Возможность | REST + OpenAPI | LangChain Tools | Google A2A | MCP |
|---|---|---|---|---|
| Нативное обнаружение AI | ❌ Ручное | ⚠️ Определено в коде | ✅ Agent cards | ✅ Нативное |
| Мульти-агентная оркестрация | ❌ | ⚠️ Custom-код | ✅ Основная цель | ⚠️ На уровне сервера |
| Двунаправленный streaming | ❌ | ❌ | ✅ | ✅ |
| Enterprise-управление | ✅ Зрелое | ❌ Нет встроенного | 🟡 Раннее | 🟡 Быстро развивается |
| Экосистема | ✅ Огромная | ✅ Большая | 🟡 Раннее | ✅ Быстро растёт |
| Орган стандартизации | ✅ OpenAPI Initiative | ❌ Вендор-специфично | ✅ Поддерживается Google | ✅ Linux Foundation |
Ключевой вывод простой: MCP и A2A — не конкуренты. MCP стандартизирует подключение агента к инструментам и данным. A2A стандартизирует общение агентов друг с другом. В серьёзной enterprise-архитектуре эти уровни дополняют друг друга.
Мы выбрали MCP по практической причине: открытый стандарт, рабочие SDK на Python и TypeScript, широкая поддержка вендоров и клиент-серверная модель, которая естественно ложится на структуру реальных enterprise-систем. Если вам нужен более прикладной разбор, посмотрите Подключение ИИ-Агентов к Внутренней CRM: Разбор Архитектуры MCP. А если у вас до сих пор живут старые Python-автоматизации, полезным продолжением будет От Script-Kiddie к Enterprise: Рефакторинг Python-скрейперов в масштабируемые бекенды FastMCP.
Когда НЕ стоит мигрировать
Это раздел, который многие статьи предпочитают обходить. А зря. Именно здесь обычно принимается правильное решение.
1. Простые CRUD-эндпоинты. Если API отдаёт GET /users/{id} мобильному приложению, и ни один AI-агент никогда его не вызовет, MCP добавит overhead без заметной пользы. REST остаётся хорошим выбором для простых детерминированных чтений.
2. Отладка сегодня сложнее. Скажу прямо: дебажить MCP-сервер в продакшене пока сложнее, чем обычный REST API. Инструментов меньше, операционной истории меньше, готовых паттернов мониторинга тоже меньше. При первом развёртывании dlab_mcp.py мы упёрлись в проблему конкурентности. FastMCP по умолчанию работал однопоточно, и при примерно 100 одновременных сессиях время отклика выросло с 85 мс до более чем 2 секунд. Исправление заняло шесть часов. Поиск причины — ещё дольше.
3. Не все поверхности должны быть доступны AI. Kubernetes liveness probe, экспортёр Prometheus, ночной пакетный ETL — всё это не нужно оборачивать в MCP только потому, что протокол сейчас на слуху. Правило простое: мигрируйте только те поверхности, которые AI-агенты реально вызывают в продакшене.
4. Протокол ещё молод. MCP существует недолго. Управление через Linux Foundation снижает риск жёсткого vendor lock-in, но спецификация всё ещё активно развивается: транспорты, аутентификация, согласование возможностей меняются быстро. Поэтому бизнес-логику лучше жёстко отделять от протокольного слоя.
Иными словами: не мигрируйте всё подряд. Мигрируйте только те точки, где AI действительно нужен детерминированный доступ к инструментам.
Если MCP-сервер получает доступ к финансовым данным, CRM или PII, не давайте ему прямую запись без approval gates, журналирования и сценария отката. Для требований GDPR Article 32 и Zero-Trust это уже не «улучшение на будущее», а базовый минимум.
REST не умер — он понижен в звании
Заголовок у статьи провокационный. Реальный тезис полезнее.
REST не умирает. Он сдвигается с уровня оркестрации на уровень транспорта.
Мы уже видели такой паттерн раньше. TCP не исчез, когда HTTP стал основным прикладным контрактом. Он просто ушёл ниже в стек. То же происходит и сейчас: MCP-серверы обычно работают поверх HTTP, SSE или stdio и нередко оборачивают уже существующие REST-интеграции.
То есть ваши REST API никуда не делись. Они по-прежнему отдают данные, принимают команды и обслуживают внешние системы. Но для AI-агента это всё чаще не тот интерфейс, с которым стоит работать напрямую.
Для компаний это, скорее, хорошая новость. Инвестиции в существующие API не пропадают. Они становятся базовым слоем, который MCP оборачивает и публикует в форме, удобной для агентов.
План миграции на 90 дней
Если вы дочитали до этого места и хотите проверить MCP на практике, вот план, которому мы сами следовали.
| Дни | Действие | Артефакт |
|---|---|---|
| 1–5 | Инвентаризация всех эндпоинтов. Маркировка P0, P1, P2. | api_inventory.csv |
| 6–10 | Выбор 3 кандидатов P2: низкий риск, высокая частота, внутреннее использование. | Документ с кандидатами |
| 11–20 | Сборка MCP-сервера. FastMCP или TypeScript SDK. | mcp_server.py с dry_run=True |
| 21–30 | Подключение AI-агента. Проверка обнаружения и вызова инструментов. | Демо-запись, логи сессий |
| 31–45 | Добавление аутентификации: OAuth 2.1, API key scoping. | Конфигурация безопасности |
| 46–60 | Деплой в продакшен с мониторингом. | Дашборд Grafana + правила алертинга |
| 61–75 | Расширение на P1-процессы со средним риском. | MCP-сервер v2 |
| 76–90 | Реальный workflow с approval gates. Измерение ROI. | Отчёт ROI |
Чекпоинт на день 90: если вы не можете показать измеримое улучшение по времени выполнения, числу ошибок, скорости внедрения новых инструментов или снижению операционного риска, MCP, скорее всего, не решает вашу задачу. И это нормальный вывод.
Если у вас в контуре ещё живёт логика 1C или SAP, не оценивайте MCP изолированно. Последовательность миграции имеет значение: сначала разберите зависимости, потом меняйте слой оркестрации. По этой теме полезна статья Миграция с устаревших систем (1C, SAP) на Odoo 19: Оценка рисков и Дорожная карта.
Как выглядит наш MCP-сервер
Это не концептуальная диаграмма. Ниже — реальный реестр инструментов из dlab_mcp.py:
# dlab_mcp.py — Боевой MCP-Сервер (FastMCP)
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("DLab Odoo Agent")
# ═══ Инструменты Блога ═══════════════════════════════
@mcp.tool()
def list_blog_posts(lang: str = "all") -> str:
"""Список всех опубликованных статей со статусом SEO."""
@mcp.tool()
def publish_article(article_num: int, lang: str = "all", dry_run: bool = True) -> str:
"""Компиляция markdown из content/blog/ и публикация в Odoo."""
@mcp.tool()
def run_seo_audit() -> str:
"""Полный SEO-аудит всех опубликованных статей."""
@mcp.tool()
def run_content_audit() -> str:
"""Аудит SSOT (content/blog/) vs боевые записи в Odoo."""
@mcp.tool()
def read_odoo_records(model: str, domain_json: str = "[]", ...) -> str:
"""Чтение записей из любой модели Odoo."""
@mcp.tool()
def write_odoo_records(model: str, record_ids_json: str, ..., dry_run: bool = True) -> str:
"""Запись/обновление записей в любой модели Odoo."""Каждый инструмент имеет типизированные параметры и docstring, который становится AI-читаемым описанием. Каждая операция записи по умолчанию идёт с dry_run=True. Агент не сможет молча изменить боевые данные без явного подтверждения.
На практике это важно не только для удобства. Если MCP-сервер имеет доступ к Odoo-моделям вроде res.partner, account.move или внутренним CRM-таблицам, вам нужны scoping прав, аудит вызовов, rollback-процедуры и сегментация по средам. Для соответствия GDPR Article 32 и EU AI Act Compliance 2026, строгий контроль доступа к инструментам — это архитектурное требование.
Если говорить совсем приземлённо, MCP особенно полезен там, где Odoo уже стал центральной системой, а вокруг него накопились десятки мелких интеграций. Типичный сценарий: один скрипт обновляет website.page, второй пишет SEO-поля в blog.post, третий синхронизирует лиды, четвёртый запускается по cron и тихо падает при изменении схемы, пятый живёт на чьём-то ноутбуке и использует старый API key. Пока скриптов два-три, это терпимо. Когда их десять, проблема уже не в коде, а в отсутствии единого контракта. MCP здесь полезен как слой нормализации: единая аутентификация, единые правила dry_run, единое логирование, единый способ дать AI-агенту доступ только к разрешённым операциям.
Часто задаваемые вопросы
MCP действительно заменяет REST API? Нет — заголовок намеренно провокационный. MCP не уничтожает REST, а опускает его ниже в стек. REST API продолжают обслуживать данные, но перестают быть лучшим верхнеуровневым интерфейсом для AI-агентов.
Что такое Model Context Protocol (MCP)? MCP — открытый стандарт, изначально представленный Anthropic в ноябре 2024 года и развивающийся в открытой экосистеме. Он даёт AI-агентам стандартный способ обнаруживать инструменты, понимать параметры и вызывать операции. Если говорить проще: это попытка сделать для AI-инструментов то, чем OpenAPI стал для классических API, но с упором на выполнение, контекст и машинную интерпретацию.
Сколько времени занимает миграция с REST на MCP? Для сфокусированной команды из 2–4 инженеров первые три эндпоинта обычно оборачиваются за 2–3 недели. Наша миграция шести скриптов в один MCP-сервер с 11 инструментами заняла две недели, включая тесты, деплой и проверку сценариев отката.
MCP достаточно безопасен для enterprise-продакшена? Может быть — если реализовать его как enterprise-систему, а не как демо. Это значит: аутентификация со скоупами, полные логи аудита, approval gates для записи, процедуры отката, сегментация сред и принцип наименьших привилегий. Сам протокол не заменяет модель безопасности.
MCP может работать рядом с существующими REST API? Да. Это и есть нормальный путь миграции. MCP-серверы оборачивают существующие API стандартизированным интерфейсом инструментов, а REST-эндпоинты продолжают работать без изменений. Начинайте с low-risk процессов, измеряйте результат и расширяйте только там, где архитектура реально доказала свою ценность.
Эта статья основана на нашем опыте перевода Odoo-интеграций и внутренних AI-инструментов на MCP, а не на универсальной модели для всех enterprise-сред. Если вы планируете давать MCP-серверу доступ к финансовым модулям Odoo, персональным данным клиентов или трансграничным процессам, отдельно проверьте требования к журналированию, approval gates, rollback-процедурам и контролям по GDPR Article 32 перед любым боевым запуском.