MCP-протокол и корпоративные базы данных: как подключить ИИ

Что такое MCP-протокол и почему корпоративные базы отдают ему доступ

MCP (Model Context Protocol) — открытый стандарт обмена контекстом между ИИ-клиентами и внешними источниками данных. Один протокол вместо десятков самописных интеграций под каждую модель, каждую базу и каждый внутренний сервис.

Ещё недавно это была игрушка энтузиастов: пара экспериментальных серверов, падения на длинных ответах, ручная правка конфигов в текстовом редакторе. Сейчас по инженерным разборам 2026 года видно другое — команды выдают агентам доступ только на чтение к продакшн-базе, логам и репозиториям через единый интерфейс. MCP перестал быть демо и стал рабочим стандартом доступа агента к данным компании.

Переломный момент — ревизия спецификации от 28 июля 2026 года. Это крупнейший архитектурный пересмотр с момента появления протокола, и именно он открыл дорогу продакшн-внедрениям: серверы без состояния, приложения MCP, задачи и корпоративная аутентификация.

Чтобы не путаться в терминах, разложим архитектуру на три части.

• Клиент, он же агент — приложение, которое думает и решает, какой инструмент вызвать: Claude, Cursor, GitHub Copilot Workspace и другие совместимые ИИ-клиенты.
• Сервер — обёртка над источником данных. Он ничего не знает про логику модели, зато знает схему таблиц, права доступа и лимиты запросов.
• Транспорт — канал связи. Локальный запуск обычно идёт через стандартные потоки ввода-вывода, сетевой вариант — через HTTP с потоковой передачей.

Такое разделение снимает главную головную боль интеграций. Модель меняется хоть каждые полгода, но сервер над базой остаётся тем же — переписывать ничего не нужно.

Про клиентскую сторону стоит помнить одно: это обычное приложение, работающее поверх моделей, доступных по API, — официальная документация тут хороший ориентир по возможностям моделей и ограничениям контекста.

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

Архитектура MCP-07–28: серверы без состояния, приложения и задачи

Ревизия MCP от 28 июля 2026 года — крупнейший архитектурный пересмотр протокола с момента его появления: серверы стали без состояния, добавился слой приложений MCP и механизм длительных задач с отслеживанием статуса.

До этой ревизии MCP-сервер держал сессию в памяти процесса. Клиент оказывался привязан к конкретному поду: тот перезапустился при деплое — и активная агентская сессия развалилась. Балансировщику приходилось держать привязку по идентификатору сессии, что в кубернетес-контуре превращалось в отдельную головную боль.

Теперь состояние вынесено наружу, в общее хранилище. Любой экземпляр сервера способен обслужить любой запрос агента. Горизонтальное масштабирование сводится к скучному «добавить реплик», а балансировка — к обычному распределению запросов без липких сессий.

Второе новшество — слой приложений MCP. Транспорт и логика интеграций разъехались: конкретные подключения (база, трекер задач, файловое хранилище, репозиторий) описываются как самостоятельные приложения со своими правами, версией и политикой доступа. Администратор выдаёт доступ не «к серверу вообще», а к конкретному приложению.

Третье — задачи. Тяжёлый аналитический запрос к продакшн-базе или агрегация логов за месяц не влезают в разумный таймаут соединения. Вместо удержания открытого канала сервер возвращает идентификатор задачи, а клиент опрашивает статус или подписывается на обновления.

Корпоративный контур собирается из этих трёх блоков почти как конструктор. Контейнер с MCP-сервером ставится за балансировщик, аутентификация выносится в единый шлюз на входе — токен проверяется в одной точке, а не в каждом сервисе отдельно. Подробнее о том, как агент ходит в базу за данными, мы разбирали в материале про локальную модель SQL, обогнавшую флагмана в тестах.

Источники при этом разводят по отдельным пулам: продакшн-база в режиме только чтения, логи, репозиторий — у каждого свои учётные данные и квоты. Агент физически не дотянется до того, что ему не выдали. Такой подход заодно ограничивает радиус поражения, если модель начнёт «фантазировать» с параметрами запроса.

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

MCP против кастомных коннекторов: сравнительная таблица подходов

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

Ниже — четыре подхода, которые реально встречаются в корпоративных внедрениях. Сравниваем по шести параметрам, которые чаще всего ломают бюджет и сроки проекта.

Параметр	Прямые вызовы API из кода агента	Кастомный коннектор под конкретную модель	MCP-сервер	MCP-сервер с корпоративным шлюзом
Скорость подключения нового источника	Быстро, пока источников один-два	Средне: нужен свой код под каждую модель	Высокая: инструмент описывается один раз	Средняя: плюс регистрация в шлюзе и согласования
Стоимость сопровождения	Растёт как N×M при росте клиентов	Растёт как N×M, плюс привязка к вендору	Ближе к N+M	N+M и отдельная команда на шлюз
Совместимость с моделями и клиентами	Своя под каждый стек	Только под целевую модель	Claude, Cursor, DeepSeek-совместимые стеки	То же плюс единая точка подключения
Гранулярность прав	На уровне кода и учётной записи базы	Своя реализация, часто крупными блоками	На уровне отдельных инструментов	Инструмент + роль + область данных
Качество аудита	Свой лог, легко забыть	Свой лог под конкретный сценарий	Единый журнал вызовов инструментов	Журнал шлюза с привязкой к пользователю
Порог входа для команды	Минимальный	Средний	Низкий-средний: спецификация открыта	Высокий: нужна инфраструктурная экспертиза

Честно о минусах. В узких высоконагруженных сценариях с жёсткими требованиями к задержке MCP иногда проигрывает: лишний сетевой переход и слой нормализации добавляют миллисекунды на каждый вызов. Если агент дёргает одну таблицу десятки тысяч раз в час, прямой запрос к базе окажется и быстрее, и дешевле. Разбор такого варианта мы делали в материале про локальную модель SQL на ноутбуке — там прямой доступ к данным решает задачу без промежуточных слоёв.

Экосистема клиентов уже широкая: Claude, Cursor, DeepSeek-совместимые стеки. Для дешёвой обработки больших объёмов контекста удобно подключать Gemini Flash — по объёму входа он ощутимо экономичнее флагманов. Список доступных моделей и их ограничения стоит сверять по официальной документации OpenAI, потому что линейки обновляются быстрее, чем внутренние регламенты компаний.

И главное: MCP-сервер сам по себе не расширяет права. Он лишь транслирует то, что разрешено на стороне базы.

Пошаговая настройка: read-only доступ ИИ-агента к продакшн-базе

Read-only доступ ИИ-агента к продакшн-базе разворачивается в четыре шага: MCP-сервер поднимают отдельным сервисом, подключают его только к реплике, публикуют узкий набор инструментов и привязывают каждый вызов к учётной записи конкретного сотрудника.

Сразу договоримся о главном: MCP-сервер — это не плагин внутри клиента и не скрипт, который агент собирает на лету. Это самостоятельный процесс в контейнере или systemd-юните, со своим сетевым контуром и своим сервисным аккаунтом. Клиент (ChatGPT, Claude Code, Cursor) стучится к нему по сети, а тот уже ходит в базу.

Дальше — самое скучное и самое важное решение. Соединение идёт на реплику, а не на мастер-узел. Отставание в одну-две секунды для аналитических сценариев значения не имеет, а вот тяжёлый SELECT на мастере способен затормозить запись для всей компании.

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

Что публиковать в качестве инструментов — вопрос дисциплины. Чем уже набор, тем меньше шансов, что модель найдёт экзотический путь к данным.

Инструмент	Задача	Ограничение
list_tables	Список таблиц и представлений	Только белый список схем
describe_schema	Колонки, типы, связи, комментарии	Без выгрузки самих данных
query_readonly	Параметризованный SELECT с подстановкой значений	Лимит 500 строк, таймаут 5 секунд, одна инструкция
aggregate_metric	Готовые агрегаты: суммы, срезы, динамика	Фиксированный перечень метрик

Пример конфигурации подключения — с плейсхолдерами вместо боевых значений:

{
  "mcpServers": {
    "corp-analytics": {
      "command": "mcp-db-server",
      "env": {
        "DB_HOST": "replica-analytics.internal:5432",
        "DB_NAME": "corp_dw",
        "DB_USER": "mcp_readonly",
        "DB_PASSWORD": "<DB_PASSWORD>",
        "DB_STATEMENT_TIMEOUT_MS": "5000",
        "DB_MAX_ROWS": "500",
        "AUTH_ISSUER": "https://sso.example.ru/realms/corp",
        "API_KEY": "<API_KEY>"
      }
    }
  }
}

Теперь про то, как понять, кто именно задал вопрос. Корпоративная аутентификация строится на штатном входе в единую систему: клиент передаёт токен сотрудника, сервер проверяет подпись по открытым ключам провайдера и достаёт из него идентификатор и адрес почты. Никаких общих сервисных ключей на всю команду — иначе аудит превращается в фикцию.

В журнал пишем сотрудника, время, имя инструмента, текст запроса и число возвращённых строк. Если в выборку попадают персональные данные, их лучше маскировать на стороне сервера до отправки в модель. Правовые нормы динамичны и требуют предварительной проверки юристами компании.

Отдельный лайфхак: не давайте агенту писать SQL руками там, где можно подставить готовый параметризованный шаблон. Подробнее про то, как локальная модель SQL обходит флагманов в тестах, мы разбирали отдельно.

В сухом остатке: реплика, read-only роль, четыре узких инструмента, лимиты и таймауты, персональный токен на каждый вызов. Клиентская сторона при этом остаётся стандартной — совместимость с моделями описана в документации OpenAI API.

Инженерная безопасность данных: маскирование, изоляция, on-premise

Инженерная безопасность MCP держится на четырёх опорах: изоляция контуров и учётных записей, маскирование данных до отправки в модель, фильтрация на стороне MCP-сервера вместо промпта и жёсткое ограничение объёма контекста.

Правовые нормы динамичны и требуют предварительной проверки юристами компании. Дальше — только про инженерию: что реально можно проверить в коде и на стенде.

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

Контур	Учётка к БД	Что уезжает в модель	Где крутится модель
dev	read-only, синтетическая копия	полные тестовые данные	облако, ок
preprod	read-only, маскированные данные	токены вместо персональных полей	облако
prod	read-only к представлениям и агрегатам	обезличенные выборки	локально, внутри контура

Маскирование — это не «убрать пару колонок». Телефон, ФИО, номер договора и адрес заменяются на стабильные токены вроде «клиент #A7F3». Таблица соответствий живёт на стороне приложения и обратно в модель не уходит никогда.

Дальше — самое частое место ошибок. Фильтрация обязана жить в коде MCP-сервера: белый список инструментов, разрешённые таблицы и колонки, обязательный LIMIT, запрет DDL и любых операций записи.

Для чувствительных контуров рабочий вариант — развернуть MCP-сервер и модель внутри периметра. Локальные LLM в Ollama спокойно тянут выборки и суммирование, а узкоспециализированная модель под SQL на ноутбуке на узких задачах показывает результат не хуже флагманов из облака.

Если смотрите в сторону локального запуска, у нас есть пошаговый разбор: Локальные LLM модели в Ollama: пошаговый запуск без сети.

Последний слой — объём контекста. Агент никогда не получает таблицу целиком: сначала схема, потом выборка по фильтру, потом агрегат. Практика простая — сотни строк на запрос, а не миллионы, иначе вы платите за токены и теряете точность.

Лимиты окна контекста у линейки моделей различаются, актуальные значения смотрите в документации OpenAI по моделям. Свои ограничения на размер ответа MCP-сервера пропишите жёстко в конфиге.

Антипаттерны и подводные камни внедрения MCP в компании

Главные грабли внедрения MCP — один сервер со сквозным доступом ко всем источникам, учётка администратора базы, бесконечный контекст без обрезки, а ещё отсутствие владельца и метрик у самого сервера.

Начнём с классики. Команда поднимает единый MCP-сервер, цепляет к нему CRM, прод-базу, файловое хранилище и git. На демо это выглядит эффектно, в проде превращается в минное поле: одна неточная формулировка в промпте, и агент тянет данные сразу из всех контуров. Разделяйте серверы по доменам — аналитика, документы, интеграции записи. Тогда сбой одного контура не утащит за собой остальные.

Вторая ловушка — учётка администратора базы. Выдать агенту максимальные права быстрее всего, но именно так сценарий «только чтение» однажды превращается в случайное удаление строк в пятницу вечером. Заводите отдельного пользователя с минимально необходимыми привилегиями и доступом к конкретным схемам.

Третий пункт — бесконечный контекст без обрезки. Когда сервер отдаёт агенту всё содержимое таблиц, окно переполняется, стоимость вызова растёт, а качество ответов падает. Ограничивайте выдачу, отдавайте агрегаты вместо сырых строк и держите жёсткий лимит на один запрос.

Дальше — безымянный сервер. Если непонятно, кто владелец MCP-инстанса, обновления, ротация ключей и разбор инцидентов повисают в воздухе. Назначайте ответственного и фиксируйте его в реестре интеграций. Метрики — соседняя боль: без счётчиков вызовов, доли ошибок, задержек и объёма переданных данных вы не заметите, что агент штурмует базу в цикле. Совместимые клиенты вроде ChatGPT подключаются к серверу как к обычному инструменту, и модели OpenAI API честно упрутся в ваш лимит, если его нет.

Последний антипаттерн — попытка закрыть одним сервером и аналитику, и операции записи. Смешивая чтение с изменением данных, вы теряете контроль над тем, что именно поменял агент. Начинайте с чтения, а запись выносите в отдельный сервер с подтверждением.

Признак	Что за этим стоит	Что делать
Агент отвечает на вопросы вне своей темы	Сервер видит лишние источники	Сузить область доступа до одного домена
В журнале базы светится учётка администратора	Нет разграничения прав	Завести пользователя только на чтение
Счёт за вызовы растёт каждую неделю	Нет обрезки контекста и лимитов	Ввести потолок на запрос и агрегаты
Никто не знает, кто отвечает за сервер	Нет владельца	Назначить ответственного, внести в реестр
Инцидент разбирают по памяти	Нет наблюдаемости	Включить журналирование вызовов

Что делать в первую неделю после запуска: прогнать чек-лист прав, включить журнал вызовов, выставить лимиты на выдачу, назначить владельца и оставить режим только чтения. Запись добавляйте не раньше, чем появится понятная картина по метрикам.

Часто задаваемые вопросы (FAQ)