Hacker News Digest

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

oq — консольный просмотрщик OpenAPI-спецификаций.
Быстро открывает swagger.json|yaml в терминале, показывает эндпоинты, параметры, примеры ответов.
Установка: go install github.com/plutov/oq@latest.
Использование: oq spec.yaml.

• Утилита «oq» — терминальный просмотрщик OpenAPI-спецификаций, упрощающий навигацию по большим YAML/JSON.
• Пользователи практикуют spec-driven development: спецификация = единый источник правды, из неё генерируют типизированный клиент и сервер.
• Название «oq» уже занято другим проектом (homebrew-установка ставит не тот пакет); автор пока не переименовывает, предлагает брать бинарь с GitHub-релизов.
• Поддержка OpenAPI 3.1 заявлена, но реализована поверх библиотеки kin-openapi, которая 3.1 пока не умеет; для простого листинга маршрутов и компонентов это работает.
• В планах — добавить возможность делать реальные HTTP-запросы прямо из viewer.

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.

MCP: случайно-универсальная система плагинов

USB-C оказался не только для зарядки и файлов, а ещё для всего, что влезет в разъём. Друг подключил тостер к монитору — и теперь тост выводится по HDMI.

То же самое с MCP (Model Context Protocol). В документации написано: «стандартизированный способ подключать ИИ-модели к данным и инструментам». Уберём слово «ИИ» — получаем универсальный разъём, куда можно подцепить что угодно.

Как автомобильная «прикуриватель-розетка» 1952 года сегодня питает телефоны и мини-печки, MCP может связывать календарь с доставкой еды, базы данных с кофеварками, Git-репозитории с умными лампочками. Протокол не осуждает ваши решения.

Параллель: когда в NFT вместо ссылки на картинку вставили саму картинку в base64, технология стала делать то, что не планировалась.

Итог: MCP — это USB-C для приложений. Пока все думают, что он «для ИИ», он уже работает как универсальный адаптер между любыми сервисами.

• MCP воспринимается как «Web 2.0-2»: повторное открытие мэшапов и RPC-вызовов, но в формате JSON-RPC для LLM.
• Главная ценность — простые, узкие API, которые даже «средний» LLM может вызвать без ошибок.
• Критика: серверы жрут контекст, не хватает инженерии под реальные потоки LLM, безопасность и спам по trust-модели 1995-го.
• Сторонники считают, что MCP — это удобный «универсальный разъём» между сервисами, независимо от наличия ИИ.
• Скептики: это временный костыль, пока LLM не научатся работать с обычными REST/OpenAPI; скоро компании закроют «дыру».