Кластер 02 показал, что у агента есть инструменты. Но как именно подключать к нему чужие сервисы — Google Drive, GitHub, базу данных, корпоративную CRM? Сегодня — про стандарт, который индустрия выбрала ответом на этот вопрос.
MCP (Model Context Protocol) — это открытый стандарт для подключения инструментов и данных к LLM-агентам. Анонсирован Anthropic в конце 2024, к 2026 поддержан почти всеми крупными игроками (OpenAI, Google, Microsoft). Решает простую, но болезненную проблему: каждое приложение раньше делало свои собственные интеграции, MCP даёт один протокол. Сделал MCP-сервер один раз — он работает с любым агентом, поддерживающим стандарт. AI-инженер думает про MCP не как про «ещё одну библиотеку», а как про USB для LLM.
До MCP каждое AI-приложение интегрировалось с каждым внешним сервисом отдельно. Cursor делал свою интеграцию с GitHub. Claude — свою. ChatGPT с плагинами — третью. Каждое приложение писало собственный код для подключения каждого сервиса.
Когда сервисов и приложений несколько — это квадратичная задача. N приложений × M сервисов = N×M интеграций. Каждая интеграция — своя архитектура, свои контракты, своя поддержка, свои баги.
В реальном мире цифры были ещё хуже: десятки агентов и сотни сервисов. Каждая компания, делающая AI-продукт, тратила месяцы на интеграции вместо собственной логики продукта. И при этом ни одна из этих интеграций не была переиспользуемой.
Это та же проблема, которую в своё время решали USB, HTTP, OAuth и любой другой удачный стандарт: превратить квадратичную сложность в линейную через общий протокол.
MCP делает то же самое: вместо «каждый агент знает, как разговаривать с каждым сервисом» — «каждый агент знает MCP, каждый сервис говорит на MCP, и они автоматически работают вместе». N+M вместо N×M.
Если в одну фразу: MCP — это стандартный способ для агента узнать у внешнего сервиса, что тот умеет, и вызывать эти умения. Это и всё.
Технически — это спецификация на основе JSON-RPC, описывающая:
Конкретного кода — минимум. Большая часть стандарта — это контракты: формат сообщений, имена операций, структура ошибок. Реализация — за тобой или за библиотеками.
В стандарте есть три основных «примитива», которые сервер выставляет агенту:
Действия, которые агент может вызвать: send_email, create_pr, query_db. Это про то, что было в Дне 6 — но теперь стандартизированное.
Данные, к которым агент может обращаться: файлы, документы, записи БД. Не «вызов действия», а «дай мне посмотреть».
Заранее заготовленные шаблоны промптов, которые сервис предоставляет агенту. «Используй вот этот промпт для анализа моих данных».
Для большинства задач — главные tools. Resources и prompts полезны, но реже. Когда говорят «подключил MCP-сервер» — в 80% случаев речь именно про инструменты.
В мире MCP две роли:
Клиент — это всё, что хочет «попросить услуг»: Cursor, Claude Desktop, твой собственный агент. Клиент знает про MCP-стандарт и умеет:
Клиент — это «маршрутизатор» между моделью и внешним миром. Бо́льшую часть работы делают готовые SDK (от Anthropic, Microsoft, opensource). Тебе как разработчику агента — не надо писать MCP-клиента с нуля.
Сервер — это «адаптер» к чему-то внешнему. Один сервер = один сервис: GitHub-MCP, Google-Drive-MCP, Postgres-MCP. Сервер выставляет наружу инструменты этого сервиса в формате MCP.
Серверы бывают разные:
Главное: один и тот же сервер работает с любым MCP-клиентом. Написал GitHub-MCP — он сразу подключается к Cursor, к Claude, к твоему агенту, ко всему, что поддерживает MCP.
MCP-стандарт описывает что передаётся, но также определяет как. Есть два основных режима:
Транспорт прозрачен — модель и большинство твоего кода не различают, по какому каналу идёт общение. Это абстракция, как HTTPS vs HTTP — снаружи одинаково.
Чтобы интуиция прижилась — пример того, как MCP работает на одном запросе агента «посмотри последний PR в моём репозитории и составь комментарий»:
list_prs, get_pr, create_comment, и т.д. list_prs». Возвращает tool call. list_prs, понимает что это из GitHub-MCP, отправляет MCP-запрос туда. messages как tool_result, делает следующий вызов модели. get_pr»... и так до завершения задачи. Заметь главное: модель ничего не знает про MCP. Для неё это просто инструменты в стандартном формате tool calling. Вся магия MCP — между клиентом и сервером. Это и есть смысл хорошей абстракции.
Не все инструменты нужно делать через MCP. Когда у тебя в агенте всего 2-3 простых инструмента, ты сам их написал, они нужны только в этом агенте — нет смысла оборачивать в MCP-сервер. Прямой tool call (как в Дне 6) проще и быстрее.
MCP начинает давать выигрыш, когда:
Для прототипа на выходных — прямые tool calls. Для продукта, который растёт — MCP стоит обдумать.
Соблазн «напишу свой MCP-сервер для GitHub» обычно лишний. Готовый GitHub-MCP уже есть, поддерживается, обновляется. Свой будет хуже, и время на него можно потратить на собственно продукт.
Писать свой MCP-сервер имеет смысл, когда: (а) для нужного сервиса нет готового, (б) ты делаешь внутреннюю интеграцию своих систем, (в) специфичная логика, которую готовые не покрывают.
«Подключим MCP — и агент сразу будет круче». MCP — это транспортный стандарт, не интеллект. Подключение MCP-сервера само по себе ничего не улучшает в работе модели. Оно даёт возможность агенту обращаться к новым данным или действиям — но как агент с ними справится, зависит от его архитектуры (Кластеры 02-03), а не от наличия MCP.
MCP без хороших инструментов и хорошего промпта — это просто красивая абстракция, не работающий продукт.
Подключение MCP-сервера = передача агенту реальных прав на твою систему. Дал GitHub-MCP — агент может комментировать PR, мерджить, удалять ветки. Дал Postgres-MCP — может выполнять SQL.
Возвращаемся к Дню 0 (безопасность) и Дню 15 (контролируемые переходы): не давай агенту больше прав, чем нужно. У хороших MCP-серверов есть конфиги read-only режима, разрешённых операций. Используй их.
Особенно осторожно с непроверенными MCP-серверами от сообщества — это код, который получит доступ к твоим данным.
Подключил 5 MCP-серверов, у каждого по 10 инструментов — теперь в system prompt модели сразу описание 50 инструментов. Это дополнительные 5000-15000 токенов на каждый запрос. По цене из Дня 8 — серьёзная статья расхода.
Подключай только реально используемые сервера. Если у сервера много инструментов — посмотри, можно ли отключить ненужные. Бо́льшая часть продуктовых агентов использует 5-10 инструментов, а не 50.
Стандарт — молодой (2024). Реализации у разных вендоров слегка расходятся, иногда есть нюансы. «Работает в Claude Desktop» не всегда значит «работает в Cursor» без правок.
К 2026 ситуация стабилизировалась, но крайние кейсы по-прежнему могут отличаться. Привычка: тестировать MCP-сервер в каждом клиенте, где собираешься его использовать. Универсальной совместимости 100% пока нет.
Если у тебя установлен Claude Desktop — открой его конфиг (Settings → Developer → Edit Config). Добавь в него filesystem MCP-сервер с путём к одной из твоих папок. Перезапусти Claude. Теперь у Claude есть доступ к этим файлам — попроси «посмотри, какие у меня там лежат файлы». Это и есть MCP в действии: добавил один блок в конфиг — агент получил новые способности. Это та самая «USB-подобность», о которой шла речь.
Открой mcp.so / awesome-mcp-servers / mcp.directory (любой из каталогов MCP-серверов). Посмотри, что уже есть: серверы для Slack, Notion, Postgres, файловых систем, GitHub, Jira, AWS, и сотен других. Это масштаб экосистемы за полтора года существования стандарта. Найди 2-3 сервера, которые могли бы быть полезны в твоём гипотетическом проекте.
Возьми идею AI-агента, над которой работаешь (или гипотетическую). Перечисли все внешние данные/действия, к которым агенту нужен доступ. По каждому — есть ли готовый MCP-сервер? Если нет — что нужно написать? Какие из них read-only, а какие — пишут данные? Какие нужны точно с подтверждением пользователя (вспоминаем Дни 0 и 15)? Это твой архитектурный план интеграций.