MCP (Model Context Protocol) — это открытый протокол, который позволяет LLM-агентам подключать внешние инструменты: базы данных, файловую систему, HTTP-запросы, рантаймы кода. Anthropic выпустила спецификацию в конце 2024 года, и с тех пор её поддержали OpenAI, Google, JetBrains и Sourcegraph. Но главное — MCP уже работает в Claude Desktop и Claude Code, и его можно настроить под свою задачу за вечер.
В статье разбираем, как поднять MCP-сервер для SQLite и PostgreSQL, какие ограничения протокола стоит учитывать, и почему «просто подключить базу» не всегда означает «агент будет работать».
Что такое MCP и зачем он нужен
MCP — это транспорты, инструменты и ресурсы. Транспорт определяет, как агент общается с сервером: через стандартный ввод-вывод (stdio) или по HTTP с SSE. Инструменты — это функции, которые агент может вызвать: выполнить SQL-запрос, прочитать файл, отправить запрос к API. Ресурсы — это данные, которые сервер предоставляет агенту для контекста: схема таблицы, содержимое документа, лог.
Ключевая идея: агент не просто генерирует текст, а вызывает ваш код. Вы контролируете, какие операции разрешены, какие данные доступны, и как логируются вызовы. Это принципиально отличается от RAG, где модель получает куски текста и сама решает, что с ними делать. В MCP модель вызывает конкретную функцию с конкретными параметрами, и вы видите каждый вызов.
Поднимаем MCP-сервер для SQLite
SQLite — самый простой старт. Сервер из официального репозитория Model Context Protocol работает «из коробки» и требует только Node.js.
Установка:
bash
npm install -g @modelcontextprotocol/server-sqlite
Затем в конфигурации Claude Desktop (или любого другого MCP-клиента) добавляете:
json
{
«mcpServers»: {
«sqlite»: {
«command»: «mcp-server-sqlite»,
«args»: [«—db-path», «/path/to/your/database.db»]
}
}
}
После перезапуска Claude получает доступ к инструментам: `read_query`, `write_query`, `create_table`, `list_tables`, `describe_table`. Агент может выполнить SELECT, INSERT, UPDATE, DELETE, создать таблицу и прочитать её схему.
Практический пример. Вы просите агента: «Найди в базе все заказы за последнюю неделю и подсчитай средний чек». Агент выполняет:
`list_tables` — видит таблицу `orders`.
`describe_table` — узнаёт колонки `created_at`, `amount`.
3. `read_query` — выполняет `SELECT AVG(amount) FROM orders WHERE created_at > date(‘now’, ‘-7 days’)`.
Всё это происходит в одном диалоге, и вы видите каждый шаг. Если запрос неверный, агент может его исправить и выполнить снова.
Ограничения SQLite. Транзакции не поддерживаются: каждый `write_query` выполняется как отдельная операция. Если агент попытается сделать BEGIN, INSERT, COMMIT — сервер выполнит их как три отдельных запроса без гарантии атомарности. Для аналитики это не проблема, для записи данных — риск.
Поднимаем MCP-сервер для PostgreSQL
Postgres-сервер сложнее, но даёт больше контроля. Установка через pip:
bash
pip install mcp-server-postgres
Конфигурация:
json
{
«mcpServers»: {
«postgres»: {
«command»: «mcp-server-postgres»,
«args»: [«postgresql://user:password@localhost:5432/mydb»]
}
}
}
Сервер поддерживает те же инструменты, что и SQLite, но с одним важным отличием: он работает в режиме read-only по умолчанию. Чтобы разрешить запись, нужно передать флаг `—allow-write`.
Практический пример. Вы просите агента: «Покажи структуру базы и найди таблицы без индексов». Агент выполняет:
`list_tables` — получает список таблиц.
Для каждой таблицы вызывает `describe_table`.
3. Выполняет запрос к `pg_indexes` через `read_query`.
4. Возвращает результат: таблицы, у которых нет индексов.
С Postgres-сервером агент может работать с представлениями, схемами, функциями — всё, что доступно через SQL, становится доступно агенту. Но есть нюанс: длина контекста.
Проблема контекста: почему агент «забывает» схему
Когда агент работает с базой данных через MCP, каждый вызов `describe_table` возвращает схему таблицы. Если таблица большая (20+ колонок с типами, комментариями, ограничениями), ответ может занимать 2–5 тысяч токенов. После 5–10 таких вызовов контекст агента забивается схемами, и он начинает «забывать» предыдущие шаги.
Что делать. Ограничьте количество таблиц, которые агент может исследовать. В SQLite-сервере можно задать `—table-prefix`, чтобы агент видел только таблицы с определённым префиксом. В Postgres-сервере используйте отдельную схему и дайте агенту доступ только к ней.
Второй подход — дать агенту инструкцию в system prompt: «Не описывай таблицы, если они уже были описаны в этом диалоге». Это снижает нагрузку на контекст, но не гарантирует, что агент не сделает лишний вызов.
Лимиты и безопасность
MCP-сервер не защищает от некорректных запросов. Если агент выполнит `DROP TABLE` — данные удалятся. Для SQLite это необратимо (если нет бэкапа). Для Postgres read-only режим спасает, но не от тяжёлых SELECT, которые могут положить базу.
Рекомендации
- Для продакшена Postgres всегда запускайте с read-only, если запись не нужна явно.
- Для SQLite используйте отдельную копию базы, не основную.
- Ограничьте время выполнения запроса через `statement_timeout` в Postgres.
- Логируйте все вызовы MCP-сервера — это единственный способ аудита действий агента.
Что дальше
MCP — это не замена RAG и не магический коннектор. Это протокол, который даёт агенту доступ к вашим данным и коду, но не гарантирует корректности или безопасности. Если вы настраиваете MCP-сервер впервые, начните с SQLite на локальной тестовой базе. Проверьте, как агент выполняет запросы, как он реагирует на ошибки SQL, и сколько шагов он может сделать до потери контекста.
Postgres-сервер стоит поднимать, только когда вы понимаете, какие запросы будут выполняться, и готовы ограничить права и контекст. В следующей статье разберём, как комбинировать несколько MCP-серверов в одном агенте — файловая система, база данных и HTTP-запросы одновременно.