Должен кое в чём признаться. Три месяца назад один из наших Python-скриптов подключался к ERP с отключённой проверкой SSL. verify=False, прямо в коде. Скрипт, который управлял опубликованным контентом на боевом сайте. Я обнаружил это во вторник, во время код-ревью, которое откладывал три недели.
Тот скрипт был одним из шести. У каждого был свой способ аутентификации в Odoo. Каждый тихо делал свою работу. Каждый был маленькой технической бомбой.
Мы удалили все шесть и заменили их одним MCP-сервером. Никто не заметил, потому что всё просто продолжило работать, только предсказуемее и без лишних рисков безопасности.
Эта статья посвящена той миграции, причинам, по которым 957 приложений в средней компании уже плохо уживаются с самодельными point-to-point интеграциями, и тому, что приходит им на смену. И не менее важно понять, когда повторять наш путь точно не стоит.
Мы удалили 6 скриптов, и никто не заметил
Вот с чем мы жили в конце 2025 года: шесть 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 к четырём серверам (dlab-mcp поверх Odoo 18, ql-mcp поверх Lead-платформы, rsoc-bot поверх PostgreSQL и telegram поверх Telegram API), где каждый сервер оборачивает бизнес-бэкенд за стандартизированным интерфейсом.
Почему 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-агенту доступ только к разрешённым операциям.
Эта статья основана на нашем опыте перевода Odoo-интеграций и внутренних AI-инструментов на MCP, а не на универсальной модели для всех enterprise-сред. Если вы планируете давать MCP-серверу доступ к финансовым модулям Odoo, персональным данным клиентов или трансграничным процессам, отдельно проверьте требования к журналированию, approval gates, rollback-процедурам и контролям по GDPR Article 32 перед любым боевым запуском.
Внедрение Odoo 19, MCP-агентов и серверной атрибуции за 6 недель
Масштабируете собственный бизнес на едином контуре CRM, ERP и диалогового ИИ или ищете надёжного White-Label инженерного партнёра для сложных проектов Odoo 19 и Meta CAPI в Европе — мы поставляем управляемую инфраструктуру с фиксированным бюджетом и сроком.