Запись архива

MCP-протокол: как стандартизация инструментов меняет разработку AI-агентов

Разбираемся, что такое Model Context Protocol (MCP), зачем он нужен разработчикам агентов, где его применять и какие ограничения стоит учитывать уже сейчас.

Схема работы MCP-протокола: клиент-серверная архитектура для AI-агентов
Схема работы MCP-протокола: клиент-серверная архитектура для AI-агентов
Career Fair at College of DuPage 2014 56 | by COD Newsroom | openverse | by

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

Почему стандарт для инструментов стал необходимым

Современные AI-агенты работают не только за счёт генерации текста — они выполняют код, обращаются к базам данных, вызывают API, читают файлы. Для этого модели используют механизм function calling: LLM генерирует JSON с именем функции и параметрами, а среда выполнения обрабатывает вызов. Однако каждая интеграция требует написания кастомного кода: спецификации функций, описание схемы, обработка ошибок, маршрутизация. При масштабировании агента до десятков инструментов поддержка превращается в головную боль.

MCP предлагает единый протокол на основе клиент-серверной архитектуры. Агент (клиент) подключается к любому MCP-серверу, который предоставляет список доступных инструментов и их схемы. Всё, что нужно разработчику — написать или использовать готовый сервер, а клиентское взаимодействие стандартизировано. Это снижает связность и упрощает добавление новых инструментов.

Что показывают официальные источники и сообщество

Официальная документация Anthropic (modelcontextprotocol.io) описывает MCP как протокол, состоящий из трёх основных компонентов: транспорт (например, STDIO или SSE), спецификация JSON-RPC и набор стандартных методов (tools/list, tools/call, resources/list и др.). В репозитории MCP на GitHub уже есть примеры серверов для файловой системы, PostgreSQL, Slack, GitHub и других популярных сервисов.

Сообщество отреагировало быстро. Один из самых цитируемых материалов — пост Саймона Уиллисона (Simon Willison, создатель Datasette), где он подробно разбирает реализацию MCP-сервера для SQLite и показывает, как протокол упрощает интеграцию с LLM. В комментариях на Reddit/r/machinelearning, правда, отмечается, что документация местами неполна, а реализация клиента на Python имеет баги при работе с асинхронными вызовами.

Практический сценарий: MCP-сервер для базы данных

Представьте, что нужно дать агенту доступ к PostgreSQL. Без MCP вам пришлось бы описать функции `select_query`, `execute_update`, `list_tables` и т.д., указать их схемы, добавить подключение к БД, обработать ошибки. С MCP вы запускаете готовый сервер `@modelcontextprotocol/server-postgres`, который понимает все стандартные методы. Агент получает список инструментов автоматически, вызывает их через единый интерфейс, а сервер берёт на себя SQL-запросы и возврат результатов.

Вот как выглядит минимальная конфигурация клиента (на Python с использованием библиотеки `mcp`):

python
from mcp import ClientSession, StdioServerParameters

запуск сервера PostgreSQL
params = StdioServerParameters(
command=”python”,
args=[“-m”, “mcp_server_postgres”, “–db”, “postgresql://user:pass@localhost/db”]
)

async with ClientSession(params) as session:
tools = await session.list_tools()
result = await session.call_tool(“query”, {“query”: “SELECT * FROM users LIMIT 5”})

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

Сравнение MCP с традиционным function calling

Чтобы понять, когда MCP оправдан, а когда — избыточен, полезно сравнить оба подхода.

Параметр Function calling (нативный) MCP
Описание инструментов Вручную в коде или в системном промпте Автоматически через протокол
Добавление нового инструмента Правка кода агента, перезапуск Запуск нового сервера, клиент подхватывает
Поддержка аргументов Статическая схема в JSON Schema Динамическая, через методы tools/list
Надёжность Зависит от реализации среды Зависит от сервера, но протокол унифицирует обработку ошибок
Сложность для одного инструмента Низкая Избыточная (нужен сервер + клиент)
Сложность для 10+ инструментов Высокая (связный код) Средняя (разделение серверов)

Протокол особенно полезен там, где инструменты меняются часто или где агент должен работать с разными наборами сервисов в зависимости от контекста. Однако для простого сценария «один агент — один API» MCP добавляет лишнюю прослойку.

Ограничения и спорные моменты

MCP — молодой стандарт, и сообщество указывает на несколько проблем.

Первое — производительность. Каждый вызов инструмента проходит через протокол JSON-RPC, что добавляет накладные расходы. В бенчмарках, опубликованных в обсуждении на Hacker News, латентность вызова MCP-сервера через STDIO примерно на 20-30% выше, чем прямой вызов функции Python. Для критичных по времени сценариев (например, быстрые вычисления) это может быть неприемлемо.

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

Третье — совместимость моделей. На данный момент MCP-клиенты реализованы в основном для Claude, но несколько экспериментальных реализаций для GPT-4 и Gemini (например, MCP client for OpenAI) не являются официальными и могут работать с перебоями.

Что можно попробовать уже сегодня

Для разработчиков, желающих оценить MCP, нет ничего проще, чем запустить готовый сервер и подключить к нему Claude Desktop или любой другой клиент, поддерживающий протокол. Anthropic предлагает набор официальных серверов для файловой системы, Git, GitHub, PostgreSQL, SQLite и других. Достаточно установить их через pip и запустить:

bash
pip install mcp-server-filesystem
mcp-server-filesystem /path/to/dir

Затем в Claude Desktop перейти в настройки > Features > Developer mode и ввести команду запуска сервера. После этого можно давать модели команды, работающие с файлами напрямую.

Полезно также изучить пример создания собственного MCP-сервера на Python или TypeScript. Это займёт около часа и даёт чёткое понимание, подходит ли протокол для ваших задач.

Итог: стандарт с потенциалом, но не серебряная пуля

MCP решает реальную проблему — стандартизацию интеграции инструментов в агентов. Он особенно полезен в экосистемах с большим числом сервисов, где каждый инструмент требует отдельной настройки. Однако протокол пока сыроват: есть вопросы к производительности, безопасности и совместимости. Для простых сценариев традиционный function calling остаётся более простым и быстрым решением.

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