Свой MCP-сервер за двадцать минут - как подключить Claude и Cursor к базе данных и логам
Два года подключение языковой модели к корпоративным базам данных выглядело одинаково: разработчик писал кастомный REST-бэкенд, вручную описывал схемы Function Calling для OpenAI, пробрасывал авторизацию и воевал с переполнением контекста. Каждый инструмент требовал отдельного велосипеда.
Открытый протокол Model Context Protocol (MCP), который запустила компания Anthropic, решил эту проблему так же, как в свое время протокол Language Server Protocol (LSP) решил проблему поддержки языков программирования в редакторах кода.
Один раз написанный MCP-сервер сегодня нативно подключается к Claude Desktop, Cursor, Windsurf, Zed и локальным моделям.
Мы собрали рабочий сервер для PostgreSQL и системных логов. Разбираем архитектуру протокола и пишем готовый сервис на Python с нуля.
Архитектура протокола: три примитива и транспорт
Протокол работает по клиент-серверной модели поверх легковесного формата JSON-RPC 2.0.
Приложение, в котором сидит пользователь (Cursor или десктопный клиент Claude), выступает в роли хоста. Хост запускает локальный процесс сервера и общается с ним через стандартные потоки ввода-вывода (stdio) или через Server-Sent Events (SSE) по протоколу HTTP.
Внутри протокола есть три фундаментальных примитива:
- Инструменты (Tools): Исполняемые функции, которые модель может вызывать для совершения действий. Например: выполнить запрос к базе данных, перезагрузить контейнер или отправить сообщение в чат. Схема аргументов передается в формате JSON Schema.
- Ресурсы (Resources): Пассивные данные, которые клиент может читать как файлы или URI-ссылки. Например: содержимое схемы базы данных, текущий лог-файл или выгрузка метрик. Ресурсы не меняют состояние системы.
- Шаблоны запросов (Prompts): Заранее заготовленные промпты с параметрами, которые пользователь может быстро вызвать через слэш-команды в интерфейсе.
Модели не отдают прямой доступ к вашей инфраструктуре. Сервер сам решает, какие функции показать модели и с какими правами их выполнить.
Пишем сервер для базы данных на Python
Кстати, если вы хотите протестировать все самые свежие модели уровня Claude Sonnet 5, GPT-5.6 или Gemini 3 в одном удобном месте и сравнить их ответы без костылей с иностранными картами - на платформе SYNTX.AI это можно сделать за пару кликов.
Для быстрой разработки используем официальный фреймворк FastMCP из пакета mcp. Он превращает стандартные функции Python с типизацией и строками документации в готовые инструменты протокола.
Ставим менеджер пакетов uv (он избавит от возни с виртуальными окружениями):
Создаем файл сервера server.py:
Код решает сразу три инженерные проблемы:
- Безопасность данных: Сессия PostgreSQL принудительно открывается в режиме readonly=True. Даже если модель составит запрос на удаление, СУБД отвергнет транзакцию на физическом уровне.
- Контроль контекста: Сервер автоматически дописывает LIMIT 50, если модель забыла ограничить выборку. Это защищает окно внимания от выгрузки миллиона строк.
- Автоматическая схема: Докстринги и аннотации типов Python парсятся библиотекой FastMCP в JSON Schema для модели без ручного описания структуры.
Подключаем сервер к Cursor и Claude Desktop
Чтобы интерфейс увидел новый сервер, его нужно прописать в конфигурационный файл.
Вариант 1. Подключение в Cursor
В корне рабочего проекта создаем папку .cursor и файл .cursor/mcp.json:
Вариант 2. Подключение в Claude Desktop
Открываем конфигурационный файл приложения:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
Вставляем ту же секцию mcpServers:
Перезапускаем редактор или приложение. В панели инструментов появится значок подключенного сервера и список доступных функций.
Как это работает в реальном диалоге
После подключения модель начинает использовать сервер как внешний орган чувств.
Пользователь пишет в чат:
"Посмотри в базе, почему у пользователя с почтой ivan@example.com завис последний платеж, и какие три заказа он оформлял до этого."
Что делает модель под капотом:
1. Запрашивает ресурс db://schema, чтобы понять, в каких таблицах лежат пользователи, транзакции и заказы.
2. Вызывает инструмент execute_sql с параметром:
3. Получив user_id, выполняет второй запрос
4. Делает третий запрос по связанной таблице заказов.
5. Формирует связный человеческий ответ с точной выжимкой из базы.
Никакого копирования структуры базы руками. Никаких догадок. Модель выполняет работу аналитика базы данных за три секунды.
Типичные грабли при развертывании
Мы собрали три ошибки, с которыми сталкиваются при первой настройке:
- Использование относительных путей в конфиге: Хост запускает сервер из своего системного каталога. Путь к скрипту server.py обязан быть абсолютным.
- Вывод лишнего текста в stdout: Протокол stdio использует стандартный поток вывода исключительно для пакетов JSON-RPC. Если вставить в код обычный print("Сервер запущен"), клиент не сможет распарсить ответ и соединение упадет с ошибкой протокола. Все логирование нужно направлять строго в sys.stderr.
- Перегрузка ресурсами: Не нужно передавать в модель терабайтные логи целиком. Ресурсы должны отдавать выжимки, схемы и метаданные, а детальный поиск должен происходить через вызов инструментов с фильтрами.
Так что, разработка интеграций для языковых моделей перестала быть написанием сотен строк костыльного кода.
Один компактный скрипт на стандартном протоколе подключает любую модель к вашей инфраструктуре за двадцать минут.