Когда AI-агент получает доступ к базе данных через MCP (Model Context Protocol), он перестаёт быть просто генератором текста и превращается в инструмент, способный выполнять реальные SQL-запросы, анализировать схемы и извлекать данные по запросу пользователя. Однако настройка такого соединения — не магия, а последовательность технических решений, каждое из которых влияет на безопасность, производительность и удобство работы.
В этой статье мы разберём, как настроить MCP-сервер для доступа к PostgreSQL, какие параметры конфигурации критически важны, и с какими ограничениями вы столкнётесь в продакшене. Материал основан на официальной документации MCP, исходном коде серверов, спецификации протокола и практическом опыте развёртывания.
Что такое MCP-сервер для базы данных
MCP — это открытый протокол, который позволяет AI-агентам (например, Claude Desktop, Copilot или пользовательским реализациям) вызывать инструменты на удалённом или локальном сервере. Сервер базы данных в этой схеме — это программа, которая принимает MCP-запросы, транслирует их в SQL и возвращает результат.
Архитектура выглядит так: клиент (агент) подключается к MCP-серверу через stdin, HTTP или WebSocket. Сервер содержит инструменты — функции, которые агент может вызывать. Для PostgreSQL типовой набор инструментов включает выполнение произвольных SQL-запросов, получение списка таблиц, чтение схемы и описание структуры.
Ключевое отличие от прямого подключения через драйвер базы данных — MCP-сервер выступает промежуточным слоем, который может добавлять логирование, ограничения, кэширование и контроль доступа. Это одновременно и преимущество, и потенциальная точка отказа.
Установка и настройка MCP-сервера для PostgreSQL
Официальный репозиторий Model Context Protocol содержит готовый сервер для PostgreSQL на Python. Установка выполняется через pip или uv, но есть нюанс: сервер требует наличия библиотек psycopg2 или asyncpg, а также доступа к базе данных.
Первый шаг — определить, будет ли сервер работать в том же контейнере, что и база, или подключаться удалённо. Для локальной разработки проще всего запускать сервер на той же машине, где работает PostgreSQL. Для продакшена — выносить на отдельный инстанс с изоляцией сети.
Установка через uv (рекомендуемый способ):
uvx mcp-server-postgres
Если вы предпочитаете pip:
pip install mcp-server-postgres
После установки необходимо указать строку подключения. Она передаётся через переменную окружения DATABASE_URL или аргумент командной строки:
DATABASE_URL=»postgresql://user:password@localhost:5432/dbname» uvx mcp-server-postgres
Здесь начинается первый критический момент: строка подключения содержит учётные данные в открытом виде. В production-среде используйте переменные окружения, менеджеры секретов или файлы конфигурации с ограниченным доступом. Никогда не передавайте пароль в аргументах командной строки — он попадёт в историю shell и системные логи.
Конфигурация pg_hba.conf и права пользователя
PostgreSQL по умолчанию не принимает удалённые подключения, а локальные может ограничивать методом аутентификации. Для MCP-сервера, который подключается к той же базе на localhost, достаточно убедиться, что в pg_hba.conf разрешено соединение через сокет или TCP с методом scram-sha-256 или md5.
Гораздо важнее — права пользователя базы данных. MCP-сервер PostgreSQL по умолчанию выполняет любые SQL-запросы, которые передаёт агент. Это означает, что пользователь, указанный в DATABASE_URL, должен иметь минимально необходимые привилегии.
Рекомендуется создать отдельного пользователя MCP с правами только на чтение (SELECT) и доступ к схеме public:
sql
CREATE USER mcp_user WITH PASSWORD ‘secure_password’;
GRANT CONNECT ON DATABASE your_db TO mcp_user;
GRANT USAGE ON SCHEMA public TO mcp_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO mcp_user;
Если агенту нужна возможность писать данные, ограничьте набор таблиц, к которым разрешён INSERT/UPDATE. Для аналитических запросов достаточно read-only. Запросы на изменение схемы (DROP, ALTER, CREATE) должны быть явно запрещены на уровне пользователя.
Инструменты, которые получает агент
После подключения MCP-сервер объявляет набор инструментов. В официальной реализации PostgreSQL доступны:
- read_query — выполнение произвольного SQL-запроса с возвратом результата в виде текста или JSON
- get_schema — получение схемы базы данных: список таблиц, их колонок, типов данных и ограничений
- get_tables — список всех таблиц в схеме
- describe_table — описание структуры конкретной таблицы
Эти инструменты позволяют агенту не только выполнять запросы, но и самостоятельно изучать структуру базы. На практике это означает, что агент может написать корректный SQL, даже если пользователь не знает точных названий таблиц.
Однако есть и обратная сторона: агент может запросить схему всей базы, включая служебные таблицы, если не настроены ограничения. В официальном сервере нет встроенного механизма фильтрации схем — это нужно реализовывать самостоятельно через обёртку или fork.
Ограничения безопасности и практические ловушки
MCP-сервер для PostgreSQL — мощный, но опасный инструмент, если не контролировать его использование. Вот основные риски, которые необходимо учитывать:
Произвольные SQL-запросы. Агент может выполнить любой SQL, который позволяет синтаксис PostgreSQL. Если пользователь базы данных имеет права на запись, агент сможет удалять данные. Единственная защита — минимальные привилегии пользователя.
Инъекция через промпты. Злоумышленник может передать агенту промпт, который заставит его выполнить вредоносный SQL. Поскольку MCP-сервер не проверяет намерения агента, он выполнит запрос, если пользователь БД имеет соответствующие права.
Утечка данных через ответы. Агент может получить доступ к конфиденциальным данным и передать их обратно в ответе. MCP-сервер не логирует и не фильтрует содержимое запросов — вся ответственность лежит на разработчике интеграции.
Отсутствие ограничения по времени. Долгие запросы могут заблокировать таблицы или исчерпать соединения. В официальном сервере нет таймаутов по умолчанию — их нужно настраивать на уровне PostgreSQL (statement_timeout) или в обёртке MCP-сервера.
Пример: как агент отвечает на вопрос по данным
Рассмотрим практический сценарий. Допустим, у вас есть база данных интернет-магазина с таблицами orders, customers, products. Агент через MCP-сервер получает задание: «Покажи топ-5 клиентов по сумме заказов за последний месяц».
Без MCP-сервера пользователь должен сам написать SQL-запрос, выполнить его в клиенте и интерпретировать результат. С MCP-сервером агент:
Получает схему базы через get_schema
Определяет, что таблица orders содержит customer_id и total_amount, а customers — name
3. Формирует SQL: SELECT c.name, SUM(o.total_amount) as total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.order_date >= NOW() — INTERVAL ‘1 month’ GROUP BY c.name ORDER BY total DESC LIMIT 5
4. Выполняет запрос через read_query
5. Форматирует результат в понятный ответ
Всё это происходит за несколько секунд, и пользователь получает готовый ответ без написания SQL. Но если права пользователя базы данных позволяют DELETE, тот же агент может случайно или намеренно удалить данные.
Альтернативные реализации и кастомные серверы
Официальный сервер — не единственный вариант. Сообщество предлагает реализации на TypeScript, Go и Rust. Кастомный сервер может добавлять:
- Фильтрацию запросов по регулярным выражениям (например, запрет DROP/ALTER)
- Логирование всех запросов в отдельную таблицу
- Ограничение количества возвращаемых строк
- Маскирование конфиденциальных колонок
- Кэширование часто выполняемых запросов
Для продакшена имеет смысл написать обёртку, которая перехватывает запросы перед выполнением. Например, на Python с использованием официального SDK:
python
from mcp.server import Server
async def handle_query(query: str) -> str:
# Проверка на опасные операции
dangerous_keywords = [‘DROP’, ‘ALTER’, ‘TRUNCATE’, ‘DELETE’, ‘UPDATE’]
if any(kw in query.upper() for kw in dangerous_keywords):
return «Операция запрещена политикой безопасности»
# Выполнение через asyncpg
result = await execute_safe_query(query)
return result
Такая обёртка — минимальная защита, но она не спасает от инъекции через сложные многоступенчатые запросы. Полная безопасность требует комбинации ограничений на уровне базы, сервера и клиента.
Практические выводы
MCP-сервер для PostgreSQL — отличный способ дать AI-агенту доступ к реальным данным, но он требует вдумчивой настройки. Перед подключением к продакшен-базе проверьте три вещи:
- Права пользователя БД: только необходимые операции, никаких DDL и массовых изменений
- Сетевая изоляция: MCP-сервер должен быть доступен только доверенным клиентам, не через публичный интернет
- Мониторинг: логируйте все запросы, проходящие через сервер, чтобы быстро выявить аномалии
Официальная документация MCP и исходный код PostgreSQL-сервера — лучшие источники для старта. Начните с локального тестового контейнера, проверьте поведение агента на типовых запросах, и только потом подключайте реальные данные. База данных — не игрушка, и MCP не отменяет базовых принципов безопасности, а лишь добавляет новый слой, который нужно контролировать.