MCP Server’s: архитектура, настройка и примеры использования

Как практик, работающий с интеграцией больших языковых моделей в продуктовую инфраструктуру, я часто сталкиваюсь с проблемой: LLM нужно дать доступ к внешним данным или действиям, но каждый раз изобретать велосипед — не вариант. Model Context Protocol (MCP) — это как раз тот стандарт, который решает эту задачу системно. В этой статье я разберу, как устроен MCP сервер, как его настроить и где применять, чтобы вы могли сразу перейти к делу, а не тратить время на поиск ответов по кусочкам.

Вы узнаете, чем MCP отличается от прямых API-вызовов и GraphQL, как спроектировать архитектуру, настроить безопасность и избежать типичных ошибок. Материал рассчитан на middle и senior разработчиков, знакомых с протоколами, но без опыта работы с MCP. Поехали.

Введение: что такое MCP Server и зачем он нужен

MCP Server — это посредник между LLM и внешними системами (базами данных, API, файлами). Он стандартизирует обмен контекстом: модель запрашивает данные или выполняет действия через единый протокол, а сервер отвечает структурированным ответом. Это избавляет от необходимости писать отдельные интеграции для каждого источника.

Проблема, которую решает MCP, — фрагментация контекста. Без него разработчики часто передают LLM сырые данные через промпты, что небезопасно и не масштабируется. MCP вводит чёткие роли: клиент (LLM или приложение), сервер (управляет ресурсами и инструментами) и транспортный слой.

История и эволюция протоколов контекста

До MCP каждый разработчик интеграции LLM решал задачу по-своему: кто-то встраивал вызовы API прямо в промпт, кто-то писал кастомные middleware. Это приводило к дублированию кода и сложностям с безопасностью. Anthropic (создатели Claude) предложили MCP в 2024 году как открытый стандарт, чтобы унифицировать этот процесс. Сообщество быстро подхватило идею — сейчас SDK доступны для Python, Node.js, Go и Java.

Проблемы ранних интеграций

Ранние подходы страдали от отсутствия стандартизации: каждый инструмент требовал своего формата запроса, не было единого механизма аутентификации и кэширования. MCP решает это через JSON-RPC как базовый протокол.

Роль сообщества и Anthropic

Anthropic выступил инициатором, но MCP — открытый стандарт. Сейчас его развивают через GitHub репозиторий, где можно найти примеры и обсуждения.

Ключевые преимущества использования MCP Server

• Стандартизация обмена: единый JSON-RPC протокол для всех источников.
• Повышение безопасности: встроенная аутентификация и авторизация на уровне ресурсов.
• Гибкость интеграции: легко подключать новые источники без изменения клиентского кода.
• Масштабируемость: поддержка асинхронного взаимодействия и кэширования.

Архитектура MCP Server: компоненты и взаимодействие

Архитектура MCP состоит из трёх ключевых компонентов: клиент (обычно LLM или приложение, которое её вызывает), сервер (управляет контекстом) и транспортный слой. Поток данных выглядит так: клиент отправляет запрос на получение ресурса или выполнение инструмента, сервер обрабатывает его (валидация, аутентификация, кэширование) и возвращает ответ.

Транспортные протоколы: JSON-RPC, WebSocket, gRPC

Выбор транспорта зависит от сценария:

Протокол	Плюсы	Минусы
JSON-RPC	Простота, совместимость с HTTP	Не поддерживает real-time без WebSocket
WebSocket	Реальное время, двусторонняя связь	Сложнее в отладке
gRPC	Высокая производительность, бинарный формат	Требует генерации кода из proto-файлов

Для простых интеграций достаточно JSON-RPC. Если нужен потоковый обмен (например, для чат-ботов), лучше взять WebSocket. gRPC оправдан при высоких нагрузках.

JSON-RPC: простота и совместимость

Стандартный выбор для первого MCP сервера. Запросы и ответы — это JSON с полями jsonrpc, method, params, id. Легко тестировать через curl.

WebSocket: реальное время

Подходит для сценариев, где LLM нужно получать обновления контекста в реальном времени (например, мониторинг систем).

gRPC: производительность

Используется в высоконагруженных системах. Требует proto-файлов, но даёт низкую задержку и поддержку стримов.

Ресурсы, инструменты и промпты в MCP

MCP оперирует тремя сущностями:

• Ресурсы — данные (файлы, записи БД, ответы API). Пример: ресурс user_profile возвращает JSON с данными пользователя.
• Инструменты — действия (поиск, расчёт, отправка письма). Пример: инструмент search_web выполняет поиск в Google.
• Промпты — готовые шаблоны запросов для LLM. Пример: промпт summarize_text принимает текст и возвращает краткое изложение.

Ресурсы: файлы, БД, API

Ресурсы — это пассивные данные. Они могут быть статическими (файл) или динамическими (результат SQL-запроса). Важно настроить кэширование для часто запрашиваемых ресурсов.

Инструменты: поиск, расчеты

Инструменты выполняют действия. Они требуют авторизации и валидации входных параметров. Например, инструмент calculate_tax принимает сумму и возвращает налог.

Промпты: готовые запросы

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

Жизненный цикл запроса контекста

1. Инициализация сессии: клиент подключается к серверу, проходит аутентификацию.
2. Запрос ресурса/инструмента: клиент отправляет JSON-RPC запрос с указанием метода (resources/read, tools/call).
3. Обработка и ответ: сервер проверяет права, выполняет действие (например, читает файл или вызывает API) и возвращает структурированный результат.

Настройка MCP Server: пошаговое руководство

Разберём настройку на примере Python SDK. Это самый популярный вариант для быстрого старта.

Установка и зависимости

Для Python:

pip install mcp

Для Node.js:

npm install @modelcontextprotocol/sdk

Для Go:

go get github.com/modelcontextprotocol/sdk

Python: pip install mcp

После установки создайте файл server.py и импортируйте Server из mcp.server.

Node.js: npm install @modelcontextprotocol/sdk

SDK для Node.js поддерживает TypeScript, что удобно для типизации.

Go: go get github.com/modelcontextprotocol/sdk

Go-версия ориентирована на высокую производительность.

Базовая конфигурация через YAML/JSON

Пример конфигурационного файла config.yaml:

server:
port: 8080
transport: json-rpc
authentication:
type: api-key
api_key: ${MCP_API_KEY}
resources:
- name: user_data
path: /users/{id}
method: GET

Параметры сервера

Порт, транспорт, таймауты. Таймаут по умолчанию — 30 секунд, для долгих операций увеличьте до 60.

Настройка ресурсов

Каждый ресурс имеет имя, путь и метод. Для защиты используйте аутентификацию.

Настройка инструментов

Инструменты описываются аналогично, с указанием параметров и возвращаемого типа.

Запуск и тестирование с помощью curl

Запустите сервер:

python server.py --config config.yaml

Проверьте здоровье:

curl -X POST http://localhost:8080/mcp -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"ping","id":1}'

Тестовый запрос ресурса:

curl -X POST http://localhost:8080/mcp -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"resources/read","params":{"uri":"user_data/123"},"id":2}'

Примеры использования MCP Server в реальных проектах

Рассмотрим три сценария, которые покрывают 80% типовых задач. Все примеры на Python, но логика универсальна.

Интеграция с поисковым API (Google Custom Search)

Создадим инструмент search_web, который вызывает Google Custom Search API.

from mcp.server import Server, Tool
import requests

server = Server("search-server")

@server.tool(name="search_web", description="Поиск в интернете")
async def search_web(query: str):
api_key = os.getenv("GOOGLE_API_KEY")
cx = os.getenv("GOOGLE_CX")
url = f"https://www.googleapis.com/customsearch/v1?q={query}&key={api_key}&cx={cx}"
response = requests.get(url)
return response.json()

Регистрация инструмента

Используйте декоратор @server.tool для регистрации. Имя должно быть уникальным.

Обработка запроса

Внутри функции вы можете вызывать любой API, БД или выполнять вычисления.

Возврат результата

Возвращайте структурированный JSON. MCP сам сериализует его в ответ.

Подключение к PostgreSQL для извлечения данных

Ресурс для выполнения SQL-запросов.

@server.resource(uri="postgres://users/{user_id}")
async def get_user(user_id: int):
conn = await asyncpg.connect(os.getenv("DATABASE_URL"))
row = await conn.fetchrow("SELECT * FROM users WHERE id = $1", user_id)
await conn.close()
return dict(row)

Настройка пула соединений

Используйте пул для избежания пересоздания соединений. Для PostgreSQL подойдёт asyncpg.

Создание ресурса

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

Выполнение запроса

Важно экранировать входные данные, чтобы избежать SQL-инъекций. Используйте параметризованные запросы.

Агрегатор данных из нескольких внешних API

Сервер, который объединяет данные от погодного API, календаря и новостей.

@server.resource(uri="composite/daily-summary")
async def daily_summary():
weather = await get_weather()
calendar = await get_calendar_events()
news = await get_news()
return {"weather": weather, "calendar": calendar, "news": news}

Определение нескольких ресурсов

Каждый источник — отдельный ресурс или инструмент.

Композитный запрос

Создайте ресурс, который агрегирует данные из других ресурсов. Это удобно для LLM.

Форматирование ответа

Возвращайте структурированный JSON, чтобы LLM могла легко его обработать.

Безопасность и аутентификация в MCP Server

Безопасность — ключевой аспект, так как MCP сервер открывает доступ к данным и действиям. Рассмотрим основные механизмы.

Виды аутентификации: API-ключи, JWT, OAuth2

Метод	Когда применять	Пример конфигурации
API-ключи	Внутренние сервисы, простота	api_key: ${MCP_API_KEY}
JWT	Без состояния, микросервисы	jwt_secret: ${JWT_SECRET}
OAuth2	Делегирование доступа	oauth2_provider: google

API-ключи: простота

Самый простой способ. Храните ключ в переменной окружения и проверяйте в middleware.

JWT: без состояния

Подходит для микросервисной архитектуры. Токен содержит информацию о пользователе и правах.

OAuth2: делегирование

Используйте, если нужно дать доступ сторонним сервисам. Реализуйте через провайдера (Google, GitHub).

Авторизация доступа к ресурсам и инструментам

RBAC (Role-Based Access Control) — стандартный подход. Определите роли (admin, user, viewer) и привяжите к ним права на ресурсы и инструменты.

Ролевая модель

Пример: admin может вызывать любые инструменты, user — только чтение ресурсов.

Политики доступа

Пропишите политики в конфигурации: для каждого ресурса укажите разрешённые роли.

Логирование попыток

Логируйте все попытки доступа для аудита. Используйте структурированные логи.

Защита от атак: rate limiting, валидация входных данных

Rate limiting защищает от перегрузок. Настройте лимиты на количество запросов в минуту для каждого клиента.

Rate limiting

Используйте библиотеки типа limits для Python. Настройте лимит: 100 запросов в минуту на клиента.

Валидация схемы

Проверяйте входные параметры инструментов через JSON Schema. Это предотвратит инъекции.

Экранирование вывода

Если ресурс возвращает данные из БД, экранируйте вывод, чтобы избежать XSS.

Производительность и масштабирование MCP Server

MCP сервер должен выдерживать нагрузку от множества параллельных запросов LLM. Рассмотрим ключевые аспекты.

Мониторинг и логирование

Настройте сбор метрик: количество запросов, время ответа, ошибки. Используйте Prometheus + Grafana.

Метрики запросов

Собирайте гистограммы времени ответа и счётчики по методам.

Логирование ошибок

Логируйте все ошибки с контекстом (метод, параметры). Используйте ELK стек для анализа.

Алерты

Настройте алерты на высокую задержку (> 1 секунды) или частые ошибки.

Кэширование контекста

Кэшируйте ответы ресурсов, которые редко меняются. Используйте in-memory или Redis.

In-memory cache

Подходит для одного экземпляра. Используйте lru_cache из Python.

Redis cache

Для распределённых систем. Настройте TTL для каждого ресурса.

Инвалидация кэша

При обновлении данных инвалидируйте кэш. Используйте событийную модель.

Горизонтальное масштабирование и балансировка

Разверните несколько экземпляров MCP сервера за балансировщиком. Общее состояние храните в Redis.

Docker Compose

Пример docker-compose.yml с сервисами mcp-server, redis, nginx.

Kubernetes deployment

Используйте Deployment с несколькими репликами и Service для балансировки.

Балансировщик

Nginx или Traefik распределяют запросы между экземплярами.

Ошибки и их обработка в MCP Server

Типичные ошибки: таймауты, неверные запросы, отказ ресурсов. Важно возвращать структурированные ответы.

Стандартные коды ошибок MCP

Код	Значение	Пример
-32700	Parse error	Неверный JSON
-32600	Invalid Request	Отсутствует метод
-32601	Method not found	Неизвестный инструмент
-32603	Internal error	Ошибка БД

-32700: Parse error

Возникает, если тело запроса не является валидным JSON. Возвращайте код -32700.

-32600: Invalid Request

Отсутствуют обязательные поля (method, id). Проверяйте схему запроса.

-32601: Method not found

Клиент запросил несуществующий ресурс или инструмент. Возвращайте с сообщением.

Retry логика и таймауты

Настройте повторные попытки для временных ошибок. Используйте экспоненциальную задержку.

Настройка retry

Максимум 3 попытки с задержкой 1, 2, 4 секунды. Для критичных операций — до 5.

Таймауты

Установите таймаут на выполнение инструмента (по умолчанию 30 секунд). Для долгих операций — 60.

Circuit breaker

Если сервис постоянно возвращает ошибки, отключайте его на время. Реализуйте через библиотеку pybreaker.

Лучшие практики и советы по эксплуатации MCP Server

На основе опыта внедрения MCP в нескольких проектах, выделю ключевые рекомендации.

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

Структурирование конфигурации и кода

Разделяйте ресурсы и инструменты по модулям. Используйте переменные окружения для секретов.

Разделение на модули

Каждый ресурс или инструмент — отдельный файл. Это упрощает тестирование.

Использование переменных окружения

Не хардкодьте пароли. Используйте .env файл и библиотеку python-dotenv.

Версионирование

Версионируйте конфигурацию ресурсов. При изменении формата ответа создавайте новую версию.

Тестирование MCP сервера

Покрывайте код юнит-тестами и интеграционными тестами. Используйте pytest.

Юнит-тесты инструментов

Тестируйте каждый инструмент изолированно, мокая внешние вызовы.

Интеграционные тесты

Запускайте тестовый сервер и отправляйте реальные запросы. Проверяйте ответы.

Нагрузочное тестирование

Используйте locust или k6 для проверки производительности под нагрузкой.

CI/CD для MCP Server

Настройте автоматическую сборку и деплой через GitHub Actions.

Сборка и тесты

При пуше в main запускайте тесты и линтеры. Если тесты пройдены — собирайте Docker образ.

Деплой в Docker

Публикуйте образ в Docker Hub или приватный registry. Используйте теги версий.

Мониторинг после деплоя

После деплоя проверяйте метрики и логи. Настройте алерт на увеличение ошибок.

Заключение и дальнейшие шаги

MCP Server — это мощный инструмент для стандартизации интеграции LLM с внешними системами. Мы разобрали архитектуру, настройку, безопасность и производительность. Теперь ваша очередь — попробуйте создать свой первый MCP сервер, используя примеры из статьи.

Для углублённого изучения рекомендую:

• Официальная документация MCP: modelcontextprotocol.io
• GitHub репозиторий с примерами: github.com/modelcontextprotocol
• Сообщество Discord для обсуждения

Также советую ознакомиться с нашими статьями: Cursor: что это и как работает инструмент для работы с базами данных и Как ИИ-ассистенты Copilot меняют подход к работе и творчеству.

Полезные ссылки и ресурсы

• Документация MCP: modelcontextprotocol.io
• GitHub репозиторий: github.com/modelcontextprotocol
• Сообщество Discord: discord.gg/modelcontextprotocol

Следующие шаги для изучения

• Создание кастомного инструмента: попробуйте написать свой инструмент, например, для работы с Telegram API.
• Интеграция с LangChain: MCP можно использовать как источник данных для LangChain агентов.
• Написание middleware: добавьте слой логирования или кэширования между клиентом и сервером.

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

Чем MCP отличается от обычного REST API?

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

Можно ли использовать MCP без LLM?

Да, MCP сервер может работать как обычный API-шлюз, но его основная ценность раскрывается при интеграции с LLM.

Какой транспорт выбрать для первого проекта?

Начните с JSON-RPC — он простой и совместимый. Если понадобится real-time, переходите на WebSocket.

Как обрабатывать ошибки в MCP?

Используйте стандартные коды ошибок JSON-RPC и возвращайте структурированные ответы с сообщением. Настройте retry логику для временных сбоев.