Hacker News Digest

Pi изначально отвергал поддержку Model Context Protocol (MCP), заявляя, что он не нужен, и даже публично критиковал его. Однако после года наблюдения за развитием MCP команда Pi пересмотрела свою позицию: протокол стал более зрелым, а необходимые изменения для его интеграции оказались полезными и для других функций, таких как Jev и Codemode. MCP был ранее доступен как расширение, но теперь включён в ядро, чтобы обеспечить лучшую интеграцию с инструментами и улучшить опыт работы с моделями, поддерживающими отложенную загрузку инструментов и динамические системные сообщения.

Ключевая мотивация — сделать инструменты более обнаруживаемыми и возвращающими структурированные данные, подобно OpenAPI, а не просто текстовые дампы. Хотя проблемы с композицией инструментов в MCP остаются, особенно из-за серверов, оптимизированных под токенную эффективность, команда Pi видит в MCP потенциал для создания удобных, скриптоподобных рабочих процессов, аналогичных CLI. Интеграция MCP в ядро позволяет лучше управлять метаданными инструментов, например, настраивать их как отложенные или специфичные для Codemode, что ранее было невозможно при использовании отдельного расширения. Таким образом, Pi решил не избегать MCP, а активно участвовать в его эволюции, чтобы сделать его более полезным в контексте современных LLM-агентов.

MCP стал жизнеспособным инструментом благодаря практическому применению в автоматизации macOS, управлении сложными системами и гибкости при изменении API, что перевесило первоначальные возражения. Пользователи применяют MCP в macOS-приложениях (rcmd, Clop, Lunar, BetterTouchTool) для управления автоматизацией через естественный язык, используя локальные модели типа Qwen и Pi. MCP позволяет избегать жесткой привязки к API, так как агенты работают с актуальным описанием инструментов, в отличие от CLI, где изменения ломают скрипты. MCP-серверы часто реализуются без шифрования (JSON-RPC по netcat) — распространённая практика в локальных сетях и доверенных средах. mcporter превращает MCP в shell-команды, интегрируя агентов в bash-пайпы и упрощая обработку ответов через jq. MCP-интеграция в Chrome DevTools эффективна благодаря структурированному доступу к внутренним состояниям браузера, недоступным через CLI. Создание MCP-сервера для личного финансового приложения с OAuth и токенами заняло мало времени — проще, чем ожидалось. Codemode не заменяет bash, а дополняет его: модель комбинирует несколько MCP-вызовов в один инструмент, повышая надёжность и снижая шум в контексте. Спор: Некоторые считают MCP избыточным по сравнению с CLI или REST API, видя в нём повторение ошибок прошлых стандартов вроде SOAP. Спор: Критики утверждают, что встраивание MCP в Pi противоречит его философии лёгкого расширяемого каркаса и приводит к «захламлению» системы. Спор: Некоторые не видят выгоды от MCP в простых сценариях, предлагая использовать субагентов вместо добавления сложности. Совет: Для enterprise-внедрения рекомендуются OpenCode, Codex, ClaudeCode и Antigravity как устойчивые харнесс-решения без зависимости от коммерческих моделей с неясной бизнес-моделью. Совет: MCP следует использовать как OpenAPI-подобный стандарт с самоописуемыми инструментами, где структурированные данные и документация позволяют автоматически обнаруживать возможности. Совет: Для работы с файлами в MCP нужна нативная поддержка загрузки/выгрузки — передача через контекст неэффективна и ограничена в большинстве харнессов. Совет: Push-уведомления от приложения к модели снизили бы нагрузку на опрос и улучшили интерактивность в долгоживущих сессиях. Совет: При использовании Pi как базового каркаса лучше оставлять MCP как расширение, а не встраивать его в ядро, чтобы сохранить гибкость и избежать избыточной сложности.

Автор утверждает, что во многих случаях сложные 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 не решают реальные проблемы, которые он предполагает решать, и что вместо него можно было бы использовать уже существующие и более зрелые технологии.

CLI-инструменты часто зависят от платформы/версии, плохо документированы и ломаются при не-ASCII вводе. Агенты путаются в управлении состоянием (например, tmux-сессиями) и теряют контекст после мелкой ошибки. Каждый вызов ещё тормозит из-за предварительной проверки безопасности.

Композиция в CLI работает через bash: цепочки tmux send-keys, sleep, base64 и т.д. MCP сегодня так не умеет.

Выход — MCP-сервер с одним «убер-инструментом»: Python-интерпретатор, сохраняющий состояние между вызовами. Пример — pexpect-mcp: виртуальное окружение + pexpect, позволяющее скриптами управлять интерактивными CLI-программами. Вместо 30 отдельных MCP-функций достаточно одной, принимающей код.

• Участники спорят, нужен ли MCP (Model Context Protocol): кто-то считает его лишним слоем, другие — полезным способом дать LLM структурированные инструменты.
• Критика: MCP ограничивает агента набором команд, не решает безопасность, дублирует OpenAPI и заставляет LLM учиться новому формату вместо bash/API.
• Альтернативы: прямое обращение к HTTP/CLI/WebSocket (UTCP), YAML-описание тулов (hooks_mcp), eval в песочнице (runjs, Bubblewrap).
• Практические проблемы: при 100+ тулов агент путается; приходится писать кучу обвязок вместо «просто вызвать API».
• Общий вывод: MCP пока выглядит сыро, требует лишних усилий и не даёт очевидных преимуществ перед строками/bash/API.