MCP: Model Context Protocol — стандарт интеграции AI-агентов

Что такое Model Context Protocol и почему это важно

Model Context Protocol (MCP) — это открытый протокол, разработанный компанией Anthropic и представленный в конце 2024 года. Его цель — стандартизировать способ, которым AI-агенты взаимодействуют с внешними инструментами и источниками данных. До появления MCP каждый AI-агент реализовывал интеграции по-своему: собственные форматы вызовов, кастомные протоколы, несовместимые плагины. Это создавало фрагментацию, усложняло разработку и ограничивало экосистему.

MCP решает эту проблему, предоставляя универсальный язык для общения между AI-моделями и инструментами. По сути, MCP делает для AI-агентов то же, что USB сделал для периферийных устройств: один стандарт подключения, работающий с любым совместимым устройством. Агент, поддерживающий MCP, может подключиться к любому MCP-серверу и использовать его инструменты — независимо от того, кто создал агент и кто создал сервер.

Архитектурно MCP основан на клиент-серверной модели. MCP-клиент (AI-агент) устанавливает соединение с MCP-сервером (источник данных или инструмент) и обменивается сообщениями в формате JSON-RPC 2.0. Протокол поддерживает три транспортных механизма: стандартный ввод/вывод (stdio) для локальных процессов, HTTP/SSE для удалённых серверов и WebSocket для двусторонней связи в реальном времени. Это даёт гибкость: инструмент может быть как локальным скриптом, так и облачным сервисом на другом континенте.

На момент написания (июнь 2025) экосистема MCP насчитывает более 200 официальных и community-серверов. Поддержка MCP реализована в Claude Code, Claude Desktop,开源 проектах Continue, Zed и других. OpenAI объявила о планах по поддержке MCP в Codex CLI (в статусе бета), Google интегрирует MCP в экосистему Vertex AI. Можно с уверенностью сказать, что MCP становится индустриальным стандартом для подключения инструментов к AI-агентам.

Архитектура MCP: примитивы, транспорт и жизненный цикл

MCP построен вокруг трёх фундаментальных примитивов: Resources, Tools и Prompts. Понимание этих примитивов необходимо для эффективной работы с протоколом. Давайте разберём каждый из них подробно.

Resources (Ресурсы) — это данные, которые MCP-сервер предоставляет агенту для чтения. Ресурсы могут быть статическими (файл конфигурации, схема базы данных) или динамическими (список issues в реальном времени, текущая погода). Каждый ресурс идентифицируется уникальным URI, имеет MIME-тип и может содержать метаданные. Агент может запросить список доступных ресурсов, подписаться на изменения ресурса или прочитать его содержимое. Например, сервер PostgreSQL предоставляет ресурс postgres://schema/public — схему базы данных в формате SQL DDL.

Tools (Инструменты) — это функции, которые агент может вызывать для выполнения действий. В отличие от ресурсов, которые только читаются, инструменты могут изменять состояние. Каждый инструмент имеет имя, описание (на естественном языке) и JSON Schema для параметров. Агент получает список инструментов при инициализации и может вызывать их, передавая параметры. MCP-сервер выполняет инструмент и возвращает результат. Примеры инструментов: execute_sql, create_github_issue, deploy_to_vercel.

Prompts (Промпты) — это шаблоны взаимодействия, которые сервер предлагает агенту. Промпт может содержать системные инструкции, примеры и параметры для заполнения. Это позволяет серверу «научить» агента правильно с собой взаимодействовать. Например, сервер для работы с базой данных может предоставить промпт с примерами эффективных SQL-запросов и объяснением структуры базы. Агент может запросить промпт и использовать его для формирования последующих запросов.

Жизненный цикл MCP-соединения состоит из трёх фаз: Initialization, Operation и Termination. В фазе инициализации клиент и сервер обмениваются версиями протокола и возможностями (capabilities). Клиент сообщает, какие фичи он поддерживает (resources, tools, prompts, sampling), сервер отвечает тем же. Эта negotiation гарантирует обратную совместимость и позволяет серверу адаптировать поведение под возможности клиента. В операционной фазе происходит обмен сообщениями, вызовы инструментов и чтение ресурсов. Фаза завершения обрабатывает graceful shutdown и очистку ресурсов.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "execute_sql",
    "arguments": {
      "query": "SELECT * FROM users WHERE active = true"
    }
  }
}

Популярные MCP-серверы: обзор экосистемы

Экосистема MCP-серверов растёт экспоненциально. Разберём наиболее востребованные серверы по категориям, чтобы вы могли оценить практическую применимость протокола.

Базы данных. Самая насыщенная категория. Доступны серверы для PostgreSQL, MySQL, SQLite, MongoDB, Redis, Elasticsearch, ClickHouse, DuckDB и других. Сервер PostgreSQL, например, предоставляет ресурсы со схемой базы данных и инструменты для выполнения SQL-запросов, EXPLAIN, управления транзакциями. Агент может не просто написать запрос, а исследовать существующую схему, найти подходящие индексы и сгенерировать оптимизированный запрос. Сервер SQLite особенно популярен для локальной разработки — он не требует установки отдельной СУБД.

Разработка и DevOps. GitHub MCP-сервер предоставляет полный доступ к GitHub API: управление репозиториями, issues, pull requests, actions, releases. Git-сервер для локальных операций: commit, branch, merge, rebase, log, diff. Docker-сервер для управления контейнерами. Серверы для AWS, GCP и Azure позволяют управлять облачной инфраструктурой прямо из AI-агента. Kubernetes-сервер даёт доступ к подам, сервисам, деплойментам.

Файловые системы и хранилища. Filesystem-сервер обеспечивает безопасный доступ к файловой системе с ограничением по директориям. S3-сервер для Amazon S3 и совместимых хранилищ (MinIO, Cloudflare R2). Google Drive и Dropbox серверы для облачных документов. Все эти серверы реализуют модель разрешений, позволяющую администратору определить, к каким путям или бакетам агент имеет доступ.

Коммуникации и управление проектами. Slack-сервер для отправки сообщений и чтения каналов. Jira-сервер для управления задачами. Notion, Linear, Asana — серверы для соответствуюших инструментов. Email-сервер (SMTP/IMAP) для отправки и чтения почты. Этот класс серверов превращает AI-агента в полноценного участника командной коммуникации.

Поиск и данные. Brave Search API сервер для веб-поиска. Puppeteer-сервер для headless-браузинга (парсинг сайтов, снятие скриншотов). Сервер для Wikipedia, arXiv, PubMed. Серверы для финансовых данных (Yahoo Finance, Alpha Vantage). Картографические серверы (Google Maps, OpenStreetMap).

Пишем свой MCP-сервер: hands-on гайд

Теория хороша, но практика лучше. Давайте напишем собственный MCP-сервер на Python, который предоставит AI-агенту доступ к системе мониторинга. Мы реализуем сервер, который может проверять статус сервисов, читать метрики и отправлять алерты. Используем официальный Python SDK от Anthropic.

Для начала установим SDK. MCP Python SDK доступен через pip и требует Python 3.10 или новее. Он предоставляет базовые классы Server, Tool, Resource и декораторы для их определения. Транспорт по умолчанию — stdio, что идеально для локальных серверов. Сервер запускается как отдельный процесс, и AI-агент подключается к нему через стандартные потоки ввода-вывода.

# Установка MCP SDK
pip install mcp

# server.py — каркас MCP-сервера
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import asyncio
import json

# Создаём сервер
app = Server("monitoring-server")

async def main():
    async with stdio_server() as streams:
        await app.run(streams[0], streams[1], 
                        app.create_initialization_options())

if __name__ == "__main__":
    asyncio.run(main())

Ключевой элемент MCP-сервера — регистрация инструментов. Каждый инструмент определяется через декоратор @app.list_tools() для декларации и @app.call_tool() для обработки вызова. Декларация описывает имя, описание и JSON Schema для параметров. Обработчик получает имя инструмента и аргументы, выполняет бизнес-логику и возвращает результат. Агент видит только декларацию и использует её для принятия решений о вызове.

# Декларация доступных инструментов
@app.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="check_service_status",
            description="Проверяет статус сервиса по имени. Возвращает HTTP код и время ответа.",
            inputSchema={
                "type": "object",
                "properties": {
                    "service_name": {
                        "type": "string",
                        "description": "Имя сервиса (api, web, db, cache)"
                    }
                },
                "required": ["service_name"]
            }
        ),
        Tool(
            name="get_metrics",
            description="Получает метрики сервиса за последние N минут (CPU, RAM, requests).",
            inputSchema={
                "type": "object",
                "properties": {
                    "service_name": {"type": "string"},
                    "minutes": {
                        "type": "integer",
                        "default": 15,
                        "minimum": 1,
                        "maximum": 1440
                    }
                },
                "required": ["service_name"]
            }
        ),
        Tool(
            name="send_alert",
            description="Отправляет алерт в систему мониторинга с указанным уровнем критичности.",
            inputSchema={
                "type": "object",
                "properties": {
                    "message": {"type": "string"},
                    "severity": {
                        "type": "string",
                        "enum": ["info", "warning", "critical"]
                    }
                },
                "required": ["message", "severity"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name == "check_service_status":
        svc = arguments["service_name"]
        # Логика проверки сервиса
        result = await check_service(svc)
        return [TextContent(
            type="text",
            text=json.dumps(result, indent=2, ensure_ascii=False)
        )]
    
    elif name == "get_metrics":
        svc = arguments["service_name"]
        mins = arguments.get("minutes", 15)
        metrics = await fetch_metrics(svc, mins)
        return [TextContent(
            type="text",
            text=format_metrics_table(metrics)
        )]
    
    elif name == "send_alert":
        msg = arguments["message"]
        sev = arguments["severity"]
        alert_id = await create_alert(msg, sev)
        return [TextContent(
            type="text",
            text=f"✅ Алерт создан: {alert_id} ({sev})"
        )]
    
    else:
        raise ValueError(f"Unknown tool: {name}")

Ресурсы в MCP-сервере определяются аналогично. Декларация ресурсов через @app.list_resources() и чтение через @app.read_resource(). Ресурсы особенно полезны для предоставления контекстной информации: схем баз данных, конфигурационных файлов, документации. В отличие от инструментов, ресурсы кэшируются клиентом, что снижает задержки при повторных обращениях.

# Определение ресурсов
@app.list_resources()
async def list_resources():
    return [
        Resource(
            uri="monitoring://services/list",
            name="Список сервисов",
            mimeType="application/json",
            description="Список всех отслеживаемых сервисов и их статус"
        ),
        Resource(
            uri="monitoring://config",
            name="Конфигурация мониторинга",
            mimeType="application/json",
            description="Пороги алертов и настройки мониторинга"
        )
    ]

# claude_desktop_config.json — подключение сервера
{
  "mcpServers": {
    "monitoring": {
      "command": "python",
      "args": ["server.py"],
      "env": {
        "API_ENDPOINT": "https://monitoring.internal",
        "API_TOKEN": "${MONITORING_TOKEN}"
      }
    }
  }
}

Безопасность MCP: модель угроз и лучшие практики

MCP — мощный протокол, и с мощью приходит ответственность. MCP-сервер, предоставляющий доступ к базе данных или файловой системе, потенциально опасен: AI-агент может случайно удалить данные, выполнить опасный запрос или раскрыть конфиденциальную информацию. Разработчики MCP предусмотрели несколько уровней защиты.

Принцип минимальных привилегий — основа безопасности MCP. Сервер должен предоставлять только те инструменты и ресурсы, которые действительно нужны агенту. Если агенту нужно только читать данные из базы, не давайте ему инструментов для записи (INSERT, UPDATE, DELETE). Если агенту нужен доступ к конкретной директории, ограничьте filesystem-сервер этой директорией, а не всей файловой системой. Каждый инструмент должен валидировать параметры и проверять права доступа.

Подтверждение опасных операций (Human-in-the-loop). MCP поддерживает механизм запроса подтверждения у пользователя для критических операций. Сервер может пометить инструмент как требующий подтверждения, и агент обязан запросить разрешение перед вызовом. Это особенно важно для операций удаления, деплоя в production, денежных транзакций. Claude Code, например, всегда запрашивает подтверждение перед выполнением shell-команд, которые модифицируют файловую систему.

Изоляция транспорта. Для локальных серверов (stdio-транспорт) процессы изолированы на уровне операционной системы. Для удалённых серверов (HTTP/SSE) критически важна аутентификация и шифрование. MCP рекомендует использовать TLS 1.3 для всех удалённых соединений и API-ключи или OAuth 2.0 для аутентификации. Никогда не передавайте секреты (токены, пароли) в URL или незашифрованных заголовках.

Аудит и логирование. Каждый вызов инструмента должен логироваться с указанием времени, параметров и результата. Это позволяет отследить, что агент делал, и откатить нежелательные изменения. MCP-серверы должны реализовывать структурированное логирование в формате JSON для интеграции с системами мониторинга и SIEM. Рекомендуется настроить алерты на подозрительные паттерны вызовов.

MCP в production: паттерны, масштабирование и мониторинг

Когда MCP переходит от экспериментов к production-использованию, возникают новые вызовы: масштабирование, отказоустойчивость, мониторинг, управление версиями. Рассмотрим ключевые паттерны и практики для надёжного production-развёртывания.

Gateway-паттерн. Вместо прямого подключения агента к десятку MCP-серверов, используйте MCP Gateway — централизованный прокси, который маршрутизирует вызовы, обеспечивает аутентификацию, rate limiting и мониторинг. Gateway выступает единой точкой входа для агентов и позволяет менять конфигурацию серверов без перенастройки агентов. Это особенно полезно в крупных организациях с десятками команд и сотнями инструментов.

Паттерн Service Registry. MCP-серверы регистрируются в централизованном реестре с метаданными: имя, версия, возможности, health-check endpoint, владелец. Агент или Gateway запрашивает реестр для динамического обнаружения серверов. Это позволяет добавлять новые инструменты без перезапуска агентов. Реестр также хранит схемы инструментов, что ускоряет инициализацию.

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

Мониторинг и observability. Production-серверы должны экспортировать метрики в Prometheus/OpenTelemetry: количество вызовов, латентность, ошибки, размеры ответов. Трейсинг (distributed tracing) позволяет отследить полный путь запроса: от агента через Gateway к конкретному инструменту. Это критически важно для отладки проблем производительности и понимания того, как агенты используют инструменты.

Будущее MCP: дорожная карта и прогнозы

MCP находится в активной разработке (версия 1.x на июнь 2025), и сообщество активно обсуждает направление развития. На основе RFC (Request for Comments) в репозитории спецификации и публичных выступлений разработчиков можно выделить несколько ключевых направлений.

Streaming-ответы. Текущая версия MCP предполагает, что инструмент возвращает полный результат одним сообщением. Для длительных операций (тяжёлые SQL-запросы, парсинг больших файлов, генерация отчётов) это создаёт проблемы с таймаутами и UX. В roadmap MCP 2.0 — поддержка стриминга ответов через Server-Sent Events и WebSocket. Агент сможет получать частичные результаты и отображать прогресс в реальном времени.

Композиция инструментов (Tool Composition). Сегодня агент вызывает инструменты последовательно. MCP 2.0 предложит механизм композиции, позволяющий объединять несколько инструментов в атомарные цепочки вызовов с поддержкой транзакционности. Например, «создать issue в Jira + создать ветку в Git + назначить задачу» как атомарная операция: либо всё успешно, либо откат.

Стандартизация семантики. Сейчас каждый сервер описывает инструменты свободным текстом. MCP 3.0 (предварительная спецификация) предполагает введение семантических тегов и онтологий: инструмент может быть помечен как «read-only», «idempotent», «audited», «billable», и агент может принимать решения на основе этих тегов. Это повысит безопасность и предсказуемость поведения агентов.

Расширение за пределы AI-агентов. MCP изначально проектировался для AI-агентов, но сообщество видит более широкое применение: как универсальный протокол для микросервисов, IoT-устройств, edge-вычислений. JSON-RPC транспорт и простая модель ресурсов/инструментов хорошо ложатся на многие сценарии, выходящие за рамки AI. Если этот тренд продолжится, MCP может стать тем же для API, чем REST стал в 2000-х.