MCP (Model Context Protocol)

1. Обзор концепции и системная проблема

До появления протокола MCP экосистема агентских инструментов страдала от классической проблемы несовместимости $N \times M$:

1. Фрагментация адаптеров: Если у вас есть 5 AI-клиентов (Cursor, Claude Desktop, Continue, внутренний CLI-агент, веб-интерфейс) и 10 источников данных (PostgreSQL, GitHub, Slack, Sentry, локальная файловая система), инженерам приходилось создавать и поддерживать 50 отдельных интеграционных коннекторов.
2. Утечка чувствительных ключей: Клиентские приложения требовали передачи прямых API-токенов в свой контекст, увеличивая поверхность атаки.
3. Отсутствие единой типизации ресурсов: Не существовало стандарта, как модель должна получать пассивные данные (документы для чтения) отдельно от активных действий с побочными эффектами (мутации в базе данных).

Model Context Protocol (MCP) решает эту проблему по аналогии с Language Server Protocol (LSP) в мире IDE: это «USB-C для искусственного интеллекта», который унифицирует взаимодействие между AI-клиентами и бэкенд-инструментами через открытый протокол JSON-RPC 2.0.

2. Архитектурная таксономия и ментальная модель

Протокол MCP основан на четком клиент-серверном распределении и оперирует тремя основными примитивами:

• 1. Tools (Активные инструменты с побочными эффектами): Выполняемые функции, которые модель может вызывать для изменения состояния внешнего мира (выполнение SQL-запроса, запуск сборки, отправка комментария на GitHub). Описываются через строгую схему JSON Schema.
• 2. Resources (Пассивные источники данных для чтения): URI-адресованные данные без побочных эффектов, которые передаются в контекст модели как документы (содержимое файлов, логи сервера, схема таблиц, документация).
• 3. Prompts (Шаблоны взаимодействия): Заранее параметризованные промпты и контекстные цепочки, которые сервер предлагает клиенту (например, готовая инструкция для аудита уязвимостей или генерации миграции).
• 4. Транспортный слой (Transport Layer):
  • stdio: запуск сервера как дочернего процесса на той же машине. Не требует сетевых портов, имеет нулевой latency оверхед.
  • SSE (Server-Sent Events): работа через HTTP/HTTPS, что позволяет подключать удаленные корпоративные микросервисы и облачные агенты.

3. Технический пайплайн и внутренняя механика

Жизненный цикл сессии по протоколу MCP проходит 4 стадии:

1. Handshake & Capabilities Negotiation (Рукопожатие): Клиент отправляет запрос initialize, декларируя свои возможности (например, поддержку уведомлений или корневых папок). Сервер отвечает перечнем своих возможностей (Tools, Resources, Prompts) и протокольной версией.
2. Dynamic Discovery (Обнаружение сервисов): Клиент запрашивает манифесты через tools/list или resources/list. Полученные описания функций и параметров автоматически транслируются в формат Function Calling для целевой LLM.
3. Execution & Context Invocation (Вызов действия): Когда модель генерирует вызов функции, клиент транслирует его в запрос tools/call к соответствующему MCP-серверу с валидированными JSON-параметрами.
4. Result Streaming & State Notification (Возврат результата): Сервер выполняет действие локально, используя собственные безопасные конфигурации (без передачи паролей клиенту), и возвращает результат в формате текста, изображений или встроенных ресурсов.

4. Практические инженерные сценарии в продакшене

01. Безопасный доступ к продакшн-БД

MCP-сервер для PostgreSQL запускается внутри закрытого VPC контура. Он открывает для Cursor или Claude Code только инструмент execute_read_only_query. Агент может анализировать схему и оптимизировать медленные запросы, не имея прямого доступа к паролю от базы и без прав на удаление данных.

02. Единый локальный инструментарий разработчика

Один раз написанный MCP-сервер для взаимодействия с корпоративным GitLab, внутренней Jira и сервисом метрик Datadog подключается одновременно к CLI-терминалу (Claude Code), графическому редактору (Cursor) и автоматизированным GitHub Actions.

03. Браузерная автоматизация с Puppeteer/Playwright

MCP-сервер управляет headless-браузером, предоставляя клиенту инструменты navigate_to, click_element, take_screenshot. Агент самостоятельно тестирует интерфейсы и валидирует дизайн без необходимости подключать сторонние тяжелые плагины.

5. Подводные камни, типовые ошибки и безопасность

• Засорение контекстного окна (Context Bloat): Подключение 15 MCP-серверов с сотней детальных JSON-схем может съесть 30 000+ токенов еще до ввода первого слова пользователя. Используйте динамическую фильтрацию или ленивую загрузку инструментов (Dynamic Tool Selection).
• Опасность сторонних серверов (Arbitrary Code Execution): Локальный MCP-сервер выполняется с полными правами вашего учетной записи ОС. Запуск непроверенных серверов через npx -y без проверки исходного кода может привести к краже локальных SSH-ключей.
• Нарушение контракта протокола через логирование: Использование стандартного console.log() или print() внутри кода сервера коррумпирует канал stdout в транспорте stdio. Пишите диагностику исключительно в stderr.