Hacker News Digest

Протокол контекста модели (MCP) — открытый стандарт, связывающий ИИ-приложения с инструментами и данными. Работает так: сервер объявляет свои возможности, приложение показывает их модели, а когда модель хочет что-то использовать, приложение вызывает сервер и возвращает результат обратно. В схеме три роли: хост (само приложение — Claude, Cursor, ChatGPT или агент), сервер (небольшая программа, предоставляющая инструменты, данные или подсказки) и модель, которая решает, что применить, но никогда не общается с сервером напрямую.

Это не REST: используется JSON-RPC поверх стандартных потоков ввода-вывода или через одну HTTP-точку, причём серверы могут отвечать асинхронно. JSON-RPC здесь лишь оболочка — MCP определяет её содержимое: методы, согласование возможностей, транспорты и аутентификацию. В спецификации есть разделы про инструменты, «машину времени» транспортов (с версией от 5 ноября 2024 года) и уязвимость «отравления» контекста.

Большинство считает MCP избыточным, так как он дублирует возможности CLI и REST-API, усложняет интеграцию и не дает реальных преимуществ. Инструмент воспринимается как громоздкая надстройка для крупных предприятий, требующая глубокой поддержки платформы. Мнения разделились: @bluegatty видит в MCP полезный слой при качественной интеграции, а @mattlondon называет его «мертвой веткой», сравнивая с устаревшими SOAP, XML и LSP из-за избыточной JSON-сериализации. Единственным ценным аспектом называют аутентификацию, чего недостаточно для принятия протокола. Рекомендуется заменить текстовый обзор кратким определением и схемами для быстрого понимания работы MCP.

Протокол Type Server Protocol (TSP) — это JSON-RPC-протокол, с помощью которого клиент запрашивает у сервера типов данные анализа Python. Сервер хранит состояние типового анализа рабочей области и отвечает на запросы о версии протокола, снимках состояния, путях поиска Python, разрешении импортов и типах (вычисленных, объявленных и ожидаемых). Протокол заимствует форматы и соглашения Language Server Protocol там, где это удобно, — например, Position и Range, а URI представляются строками; методы используют префикс typeServer/.

Авторитетные определения протокола — файлы typeServerProtocol.ts (интерфейсы TypeScript), tsp.json (машиночитаемая модель) и tsp.schema.json (JSON-схема). Версии семантические: в ветке 0.x минорные изменения могут ломать совместимость, патчи — нет. История: 0.1.0 — начальная, 0.2.0 — новые типы запросов и поля, 0.3.0 — более сложные формы типов, 0.4.0 — объединение Type и типовые нагрузки на основе заглушек, 0.4.1 — многосоединённая согласование и управляющий запрос typeServer/connection.

Клиент запускает сервер и общается по основному соединению JSON-RPC (stdio или Node IPC; при stdio stdout зарезервирован под протокол). Типичный старт: инициализация общего состояния (обычно через LSP initialize/initialized), вызов typeServer/getSupportedProtocolVersion со сверкой semver, затем typeServer/getSnapshot для первого идентификатора снимка, после чего идут запросы типов, импортов и путей поиска с указанием текущего снимка; при устаревании результатов сервер шлёт typeServer/snapshotChanged. Дополнительные соединения — необязательная оптимизация: они открываются только после согласования и обслуживают лишь read-only запросы, тогда как основное соединение владеет изменяемым состоянием. Ошибки кодируются стандартно: -32802 (ServerCancelled) при устаревшем снимке с возможностью повтора, -32602 (InvalidParams) при некорректных параметрах, -32603 (InternalError) при внутреннем сбое; сообщения не должны раскрывать секреты. Чек-лист совместимости требует корректного semver, сериализации по артефактам, неубывающих неотрицательных снимков, инвалидации при изменениях документов и конфигурации, retryable-ошибок на устаревшие снимки, нулевых UTF-16 координат LSP, корректных результатов разрешения импортов и типовых запросов, а также честного объявления многосоединённого режима с отклонением LSP-трафика и изменяющих состояние уведомлений на дополнительных соединениях.

Пользователи скептически относятся к TSP, критикуя его за избыточность и узкую специализацию под Python. @nextaccountic считает протокол попыткой Microsoft сохранить контроль над Pylance, тогда как @dev_l1x_be видит в нем способ стандартизации для сторонних чекеров. @anonymous908213, @Blackarea и @pantsforbirds называют TSP слишком общим именем для инструмента, который, в отличие от универсального LSP, поддерживает только Python. При этом @Wilfred и @Tarean отмечают, что TSP дает более структурированное и машиночитаемое представление типов, чем строки или Markdown в LSP. Мнения разработчиков разделились: maintainer basedpyright (@nikolatt) критикует TSP, а чекер Ty от Astral планирует его поддерживать. Сообщество недовольно фрагментацией инструментов анализа Python (pyright, pylance, basedpyright, cursor-pyright), что, по мнению @PufPufPuf, ведет к несогласованности результатов в разных IDE. @rjbwork, @YuechenLi и @FacelessJim воспринимают экосистему языка как набор «костылей» и хаков, которые пытаются исправить спустя десятилетия.

Автор утверждает, что во многих случаях сложные MCP серверы избыточны, и предлагает использовать простые Bash скрипты и код вместо них. Для работы с браузером он демонстрирует минимальный набор из четырех инструментов: запуск Chrome, навигация, выполнение JavaScript и скриншоты, реализованных через Node.js скрипты с Puppeteer Core. Этот подход избегает проблем с контекстом, которые создают популярные MCP серверы вроде Playwright MCP (21 инструмент, 13.7k токенов) и Chrome DevTools MCP (26 инструментов, 18.0k токенов).

Главное преимущество предложенного подхода — простота и компонуемость. Вместо десятков сложных инструментов с подробными описаниями, которые занимают значительную часть контекста агента, используются легковесные скрипты, которые можно легко расширять или заменять. Автор подчеркивает, что агенты хорошо умеют работать с Bash и писать код, поэтому нет необходимости в дополнительных абстракциях в виде MCP серверов.

• MCP представляется как универсальный способ подключения LLM к внешним инструментам, но на практике он оказывается всего лишь оберткой над REST/CLI, не решая фундаментальные проблемы безопасности и контроля доступа, и в большинстве случаев не более чем JSON-RPC поверх HTTP.

• Критика в основном сводится к тому, что MCP не предоставляет никакой ценности, кроме как способа описать API, и что вместо него можно было бы просто использовать существующие стандарты, такие как OpenAPI или GraphQL.

• Участники обсуждения также отмечают, что MCP не решает проблему аутентификации и безопасности, и что вместо него можно было бы использовать уже существующие решения, такие как OAuth.

• Некоторые участники также высказывают мнение, что вместо того, чтобы использовать MCP, можно было бы просто использовать уже существующие инструменты, такие как curl или httpie, и что MCP не предоставляет никакой дополнительной ценности.

• В целом, обсуждение показывает, что MCP не решают реальные проблемы, которые он предполагает решать, и что вместо него можно было бы использовать уже существующие и более зрелые технологии.