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

Про MCP-серверы я думаю часто — сам поднимал их под свои задачи, один для Яндекса, второй для своей базы знаний, и набил на этом достаточно шишек, чтобы захотеть разобраться, что вообще происходит. Разбираю, как устроен протокол, почему спецификация меняется так часто и почему один и тот же сервер подключается к Claude Code, Cursor, OpenCode и Pi совершенно по-разному.

Если коротко, MCP (Model Context Protocol) — это «открытый» стандарт, который позволяет ИИ-агенту получить доступ к инструментам и источникам данных через общий интерфейс. Проще говоря, прослойка между языковой моделью и всем внешним миром: через него агент дотягивается до локальных файлов, баз данных, поисковиков, калькуляторов, а теперь ещё и до интерактивных интерфейсов.

Идея простая: вместо отдельных интеграций под каждое приложение клиент использует один механизм работы с LLM-моделями. Разработчик один раз делает MCP-сервер, и агент сам находит нужные инструменты через стандартный интерфейс — вручную писать интеграцию к каждому сервису не нужно. Если приводить аналогию, это своего рода USB Type-C разъём, к которому подключаются разные устройства. По-хорошему звучит как мечта: написал один раз — работает везде. Но есть нюансы, о них чуть позже.

Появился он не от большой любви к открытым стандартам, а от внутренней боли Anthropic. В ноябре 2024 года они запустили MCP как «маленький open-source эксперимент» — протокол, который даёт моделям контекст. Идея была очевидная: у каждого LLM-приложения свои интеграции с тулами, и это не масштабируется. Если присоединить «разъём» один раз, то и источники данных, и инструменты, и промпты подключаются единообразно.

Дальше понеслось. За год MCP стал де-факто стандартом для подключения данных к LLM. Спецификация при этом менялась стремительно. Хронология развития:

Устройство сервера предсказуемое: разработчик описывает в нём набор функций (tools), которые модель может вызвать, ресурсы (файлы, БД, API) и шаблоны промптов. Всё общение с агентом идёт по JSON-RPC — запросы, ответы, вызовы инструментов. Запускается сервер либо локально через stdio (агент сам поднимает процесс), либо удалённо по HTTP.

Спецификация 2026-07-28 вышла как финальный релиз 28 июля 2026 — до этого, с мая, ходил под rc (release candidate). Она крупнейшая с момента запуска, которая меняет "правила игры" для разработчиков.

Раньше, чтобы дёрнуть тулзу через Streamable HTTP, сначала надо было сделать handshake инициализацию, получить Mcp-Session-Id и таскать его в каждом запросе. Теперь сессия и handshake выпилены полностью. Версия протокола, информация о клиенте и capabilities едут в _meta прямо внутри каждого запроса. Любой запрос может приземлиться на любой экземпляр сервера — значит, для горизонтального масштабирования больше не нужны sticky-роутинг и общее хранилище сессий.

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

Сервер теперь может отдавать интерактивные HTML-интерфейсы, которые хост рендерит в sandboxed фреймах. Инструмент объявляет шаблон UI заранее, хост его кеширует и проверяет на безопасность, а дальше UI общается с хостом всё по тому же JSON-RPC.

Также переехали из экспериментального ядра в расширение. Жизненный цикл подогнали под stateless-модель: сервер отвечает на tools/call хендлом задачи, а клиент гоняет её через tasks/get, tasks/update, tasks/cancel.

Клиенты теперь обязаны валидировать iss по RFC 9207, декларировать application_type при динамической регистрации OIDC-клиента и делать ещё несколько вещей, которые сближают MCP с настоящими OAuth/OIDC-деплойментами.

У каждой фичи теперь стадии Active → Deprecated → Removed, между deprecation и удалением минимум 12 месяцев. Это ответ на главную боль прошлого года — когда фичи ломали без предупреждения. Уже в этом релизе под deprecated попали Roots, Sampling и Logging.

inputSchema и outputSchema стали заметно мощнее: композиция через oneOf/anyOf/allOf, ссылки через $ref/$defs, а structuredContent теперь любое JSON-значение. Вся эта красота работает только там, где клиент реально поддерживает новую версию. Тут начинается боль.

Главная боль MCP в 2026 году — не сам протокол, а то, что между разными агентами он реально живой и разный. Формально все поддерживают MCP, — «написал один раз, работает везде». На практике каждая компания-разработчик агента тянет одеяло на себя, и это выливается в конкретные грабли.

Разная глубина поддержки спецификации. Claude Code грепает свежие версии, Cursor и Cline идут своим темпом, OpenCode — свой SDK, Pi — свои провайдеры, KiloCode — третий выводок. У каждого агента своя версия SDK и своя поддержка транспортов: кто-то только stdio, кто-то Streamable HTTP, кто-то по-прежнему гоняет SSE. Сервер, написанный под 2026-07-28, со stateless-ядром и новыми заголовками, в агенте, который заморозился на 2025-11-25, просто не взлетит: handshake, который от тебя больше не требуется, он всё ещё ждёт, а новые заголовки Mcp-Method/Mcp-Name расценит как мусор.

Экспериментальные фичи, которые стреляют в спину. Классика — Tasks в 2025-11-25. Пока это было экспериментальное ядро, часть агентов на него подсела, часть — нет. Теперь Tasks переехал в расширение и изменил жизненный цикл: tasks/list вообще выпилен, создание задач стало прерогатива сервера (server-directed). Если ты набил интеграцию под старый API — садись и переписывай.

Каждый агент — своя конфигурация и свои нюансы. У Claude Code свой способ подключения серверов, у Cursor — .cursor/mcp.json и свои ограничения, у Cline — отдельное меню, у OpenCode — свой конфиг. То, что идеально подключилось к одному агенту, в другом не подхватывается: разные пути, разные форматы настроек, разное поведение с локальными и удалёнными серверами. Один MCP-сервер приходится регистрировать и танцевать вокруг него для каждого агента отдельно.

Вместо того чтобы всем вместе докрутить один нормальный универсальный протокол, компании, которые делают агентов, добавляют в MCP свои вкусовые расширения и тащат его в свою сторону. Кто-то свои экспериментальные фичи, кто-то собственные способы UI, кто-то свою авторизацию. Плюс рядом живут параллельные подходы от крупных игроков, которые тоже хотят задать свой стандарт. В итоге рядовой разработчик, вынужден гонять одну и ту же историю по N агентам и молиться, чтобы каждый нормально переварил спецификацию.

Забавный парадокс. Стандарт, который задумывался как "USB Type-C" для ИИ, на практике превращается в кучу переходников. Модель «write once, integrate everywhere» работает в идеальном мире и в маркетинговых постах, а в реальности ты дописываешь обёртки, версии и конфиги под каждого клиента.

Если задуматься о реализации своего MCP-сервера с нуля, протокол на первый взгляд не кажется сложным: JSON-RPC метод, тулы, ресурсы, транспорты. Но как только речь заходит о том, чтобы поддержать несколько агентов и успеть за обновлениями спецификации, руками писать JSON-RPC и транспорты — путь в никуда. На помощь приходят библиотеки, которые помогут закрыть большинство кейсов. Сейчас в Go фактически два игрока, которые реально стоит рассматривать. Думаю, что они подвинутся для третьего кандидата.

mcp-go — пожалуй, лучший и самый универсальный выбор для Go. Это зрелая, активно развивающаяся реализация с ~9k звёзд на GitHub и сотнями коммитов. Проект быстро догоняет новые версии спецификации, включая stateless-ядро 2026-07-28, и умеет все транспорты: stdio, Streamable HTTP, SSE и даже In-Process. API построен так, чтобы ты фокусировался на бизнес-логике, а не на протокольных деталях: создать сервер — пара строк, добавить тул — mcp.NewTool с описанием и схемой параметров, и вперёд. Плюс есть middleware, хелперы для тестов и даже OpenTelemetry-трейсинг. Всё это делает его хорошей отправной точкой, если хочешь один сервер с минимумом возни.

mcp-golang — ещё одна популярная альтернатива (~1.2k звёзд). Отличается фокусом на скорости разработки через рефлексию: ты описываешь Go-функцию с её параметрами, а библиотека сама генерирует JSON-схемы для MCP. Есть клиент и сервер, поддержка stdio, SSE и stateless HTTP. Но развитие заметно более спокойное — последние изменения в основном 2025 года, и с быстрым следованием за свежими версиями спецификации, включая все нюансы 2026-07-28, тут может быть посложнее. Для прототипа или среднего проекта — отличный вариант, для жёсткого следования за свежим протоколом лучше присмотреться к mcp-go.

Если коротко: для Go я бы по умолчанию брал mcp-go — он живее, полнее и лучше успевает за изменениями спецификации, и подходит при любом уровне разработки от пет-проектов до энтерпрайза, а это в мире MCP сейчас главное.

MCP — отличная идея и действительно нужный стандарт: единый способ подключения агентов к данным и инструментам вместо зоопарка частных интеграций. За полтора года он прошёл путь от эксперимента Anthropic до индустриальной площадки, и это, безусловно, прогресс отрасли. Но в 2026 году главный барьер — не протокол сам по себе, а то, что вокруг него.

Новая спецификация 2026-07-28 — stateless-ядро, расширения, политика жизненного цикла фич — это шаг в правильную сторону и ответ на многие прежние боли. Полный JSON Schema, выпиливание handshake, 12-месячный deprecation-период — всё это делает протокол честнее и стабильнее. Вопрос лишь в том, подтянутся ли за ним сами агенты. Потому что в конечном итоге протокол «открыт» ровно настолько, насколько открыты клиенты, которые его реализуют.