Разработчик сегодня утром — 4 июля 2026 года — опубликовал на GitHub утилиту mcpsnoop и представил ее на Hacker News в разделе Show HN, охарактеризовав как «Wireshark для MCP». Такая формулировка архитектурно точна: mcpsnoop представляет собой прозрачный прокси, который встраивается непосредственно в канал передачи данных между агентом кодирования на базе ИИ и его серверами Model Context Protocol (MCP), пересылая каждый байт клиенту в продакшене и одновременно копируя каждый кадр JSON-RPC в интерфейс живого терминала. Проблема, которую он решает, носит структурный характер. Когда агент ИИ ведет себя непредсказуемо — молча пропуская вызов инструмента, зависая в ожидании ответа или согласовывая иной набор возможностей, чем ожидалось, — единственный способ зафиксировать этот сбой в реальном клиентском трафике — это оказаться непосредственно в этом канале. mcpsnoop — первый инструмент с нулевой конфигурацией, реализованный в виде единого бинарного файла, который делает это для MCP.
Почему существует пробел в отладке
Протокол Model Context Protocol набрал масштаб быстрее, чем сопутствующие инструменты. С момента, когда Anthropic представила его как открытый стандарт в ноябре 2024 года, MCP достиг 97 миллионов загрузок SDK ежемесячно и более 10 000 активных публичных серверов по состоянию на март 2026 года, при этом нативную поддержку ему обеспечили OpenAI, Google DeepMind, Microsoft и AWS. В декабре 2025 года Anthropic передала MCP в ведение Agentic AI Foundation — целевого фонда под эгидой Linux Foundation, соучредителями которого выступили Anthropic, Block и OpenAI. Теперь он лежит в основе каждого крупного агента кодирования на базе ИИ — включая Claude Code, Cursor и GitHub Copilot.
Этот рост породил проблему отладки, которую команды решали неэффективно. Когда вызов инструмента молча не выполняется, или приходит с неожиданными аргументами, или зависает на неопределенный срок, разработчики обычно обращаются к лог-файлам. Но вызовы инструментов и их результаты распределены по логам серверов, а это означает, что для восстановления действий конкретного запуска агента требуется сопоставление логов со всех задействованных серверов — процесс, который плохо масштабируется по мере усложнения агентных приложений.
Официальный ответ проекта MCP — это MCP Inspector, интерактивный инструмент тестирования, который может выполнять вызовы инструментов и инспектировать поведение сервера. Однако Inspector подключается как собственный независимый клиент — он функционирует как тестер API в стиле Postman, который находится рядом с реальным каналом связи, а не внутри него. Он не видит трафик между клиентским приложением в продакшене (Claude Desktop, Cursor, Claude Code) и фактическим сервером. Инструмент, который молча не вызывается или вызывается с неожиданными аргументами, невидим для Inspector, поскольку этот сбой проявляется только в реальном производственном трафике, а не в независимых тестовых вызовах Inspector.
mcpsnoop находится непосредственно в канале
mcpsnoop решает проблему, занимая канал передачи данных напрямую, а не наблюдая со стороны. Разработчик изменяет всего одну строку в конфигурационном файле своего MCP-клиента — оборачивая существующую команду сервера в mcpsnoop -- — и прокси берет управление на себя: он запускает исходный сервер, пересылает каждый байт без изменений и отправляет копию каждого кадра JSON-RPC в хаб-процесс через сокет Unix и на дисковые логи.
Задача хаба — обеспечить живой интерфейс терминала — TUI, который отображает поступающие кадры по мере их прибытия, с цветовой кодировкой по типу, с пометками об ошибках и медленных вызовах. Поскольку прослойка (shim) и хаб обмениваются данными через известный сокет, а не через сигнал запуска, ни одному из процессов не нужно запускаться первым. Интерфейс можно открыть до или после начала сеанса работы ИИ-клиента, и он восстанавливает сеансы, завершившиеся, пока он был закрыт. Для разработчиков, которые оставляют клиент работать во время итераций над серверным кодом, эта гибкость имеет большее значение, чем может показаться на первый взгляд.
Инструмент написан на Go и поставляется в виде единого бинарного файла без зависимостей от среды выполнения — его можно установить через go install или Homebrew. Одно это дизайнерское решение отличает его от корпоративных решений для мониторинга, которые требуют инструментирования самого кода приложения.
Что mcpsnoop обнаруживает, чего не могут логи
Протокол MCP использует JSON-RPC 2.0, и стоит разобраться в тонкости его схемы ответа инструмента: вызов инструмента может вернуть успешный ответ JSON-RPC на уровне HTTP, но при этом содержать ошибку на уровне приложения в поле result.isError. Стандартный мониторинг логов — отслеживание кодов ответа HTTP — полностью пропускает это. mcpsnoop явно помечает эти ошибки на уровне инструментов в потоке, выявляя различие между «вызов был сделан и вернул ответ» и «сам инструмент сообщил об ошибке».
Кроме того, набор функций инструмента напрямую соответствует тем режимам сбоев, с которыми чаще всего сталкиваются разработчики агентных рабочих процессов:
Живая потоковая передача с пометкой ошибок фиксирует медленные вызовы, ошибки на уровне протокола и ошибки на уровне инструментов в едином представлении. Функция воспроизведения (Replay) позволяет повторно запустить любой захваченный вызов инструмента на свежей, изолированной копии сервера, что дает разработчикам возможность воспроизвести и итерировать конкретный сбой без необходимости снова запускать весь сеанс агента. Инспектор возможностей показывает, что именно было согласовано клиентом и сервером при рукопожатии, делая расхождение в наборах возможностей между версиями серверов немедленно видимым, вместо того чтобы требовать сравнения двух отдельных лог-файлов. Обнаружение зависших вызовов отображает живой таймер для запросов в полете, поэтому застрявший инструмент становится очевиден с первого взгляда. Фильтр запросов принимает токены, такие как tool:, status:, dir:, kind:, и простой текст, которые можно комбинировать в одном выражении — tool:search status:slow сужает поток до медленных вызовов инструмента поиска без какой-либо предварительной подготовки.
Для разработчиков, работающих с потоковыми HTTP-серверами вместо stdio, mcpsnoop также работает как обратный прокси: mcpsnoop http --target http://localhost:3000/mcp --listen :7000 требует только целевой URL и адрес прослушивания.
Как отладка трафика MCP обрабатывалась ранее
Преобладающий корпоративный подход к наблюдаемости MCP — это инструментирование OpenTelemetry. Например, Grafana Cloud предлагает предварительно созданные панели мониторинга наблюдаемости MCP, охватывающие производительность инструментов, состояние протокола, использование ресурсов и отслеживание ошибок — производственное решение для команд с выделенными инвестициями в инфраструктуру. Корпоративные команды также настраивали распределенную трассировку для многоагентных рабочих процессов с использованием OpenTelemetry.
Но подходы, основанные на инструментировании, имеют общий недостаток: они требуют изменений в коде. Добавление экспортера OpenTelemetry к серверу MCP, который разработчик не контролирует, — стороннему серверу, проприетарному развертыванию клиента — не всегда возможно. Операционные проблемы наблюдаемости между серверами: расхождение запросов, частичные сбои инструментов и молчаливое расхождение схем между версиями серверов, могут подорвать надежность агента даже для команд, которые вложили значительные средства в инфраструктуру мониторинга.
Таблица сравнения mcpsnoop в его README прямо указывает, чем он отличается от своего ближайшего предшественника, mcp-trace: он добавляет запуск с нулевой конфигурацией, инспектор возможностей, воспроизведение вызовов и автономный бинарный файл без зависимостей от среды выполнения. Архитектурный пробел, который он закрывает — между «инструментом, который мы можем наблюдать в тесте» и «инструментом, который мы можем наблюдать в продакшене с нашим реальным клиентом» — оставался открытым как для Inspector, так и для mcp-trace.
Инструментарий следует за внедрением, в конечном итоге
Сроки появления mcpsnoop отражают закономерность в развитии инфраструктуры: вторичные инструменты — отладка, наблюдаемость, тестирование — имеют тенденцию отставать от кривой внедрения основного протокола. В декабре 2025 года управление MCP было передано фонду, что гарантирует его долгосрочную нейтральность как кросс-вендорного стандарта. Давление по созданию полной экосистемы — не только протокола — теперь все больше ложится на независимых разработчиков.
mcpsnoop находится в состоянии pre-1.0 и следует семантическому версионированию. На треке 0.x минорные выпуски могут изменять поведение, видимое пользователю; исправления (patch releases) — это исправления ошибок. Разработчикам, оценивающим его для отладки в продакшене, следует учитывать поверхность API. Также стоит учесть примечание о безопасности в README: mcpsnoop запускает оборачиваемую им команду сервера, поэтому разработчикам следует оборачивать только те серверы, которым они доверяют, а недоверенные серверы запускать внутри контейнера.
Инструмент доступен по адресу github.com/kerlenton/mcpsnoop и может быть установлен сегодня.
Чем mcpsnoop отличается от официального MCP Inspector?
MCP Inspector подключается как собственный независимый клиент и не видит трафик между производственным ИИ-клиентом (Claude Desktop, Cursor, Claude Code) и фактическим сервером. Он тестирует поведение инструмента извне. mcpsnoop находится внутри канала передачи данных — это прослойка, которую запускает производственный клиент, — поэтому он видит именно то, чем обмениваются реальный клиент и реальный сервер, включая вызовы, которые молча не были сделаны, запросы с неожиданными аргументами и согласования возможностей, которые дают иные результаты, чем ожидалось. Разница такая же, как между выполнением тестового запроса к API и наблюдением за реальным трафиком из другого приложения.
Требует ли mcpsnoop изменений в коде ИИ-клиента или MCP-сервера?
Нет. Разработчики добавляют одну строку в конфигурационный файл своего MCP-клиента, оборачивая существующую команду запуска сервера с помощью mcpsnoop --. Ни ИИ-клиент, ни MCP-сервер не требуют модификации. Это ключевое практическое преимущество перед подходами на основе OpenTelemetry, которые требуют добавления кода инструментирования в сервер.
Каков риск запуска mcpsnoop против стороннего MCP-сервера?
mcpsnoop выполняет оборачиваемую им команду сервера, что означает, что он работает с теми же правами и уровнем доверия, что и исходная команда сервера. В README указано, что разработчикам следует оборачивать только те серверы, которым они доверяют, и запускать недоверенные серверы вместо этого в контейнере. mcpsnoop никуда не отправляет захваченный трафик — кадры попадают в локальный сокет Unix и на дисковые логи на машине разработчика. Инструмент имеет лицензию MIT и является открытым исходным кодом; полный исходный код доступен для проверки.
Как mcpsnoop обрабатывает MCP-серверы, использующие HTTP вместо stdio?
Для потоковых HTTP-серверов — тех, которые принимают соединения через HTTP, а не через стандартный ввод/вывод — mcpsnoop работает как обратный прокси вместо прослойки stdio. Разработчик указывает mcpsnoop http на URL сервера и выбирает локальный порт прослушивания; ИИ-клиент подключается к mcpsnoop, а не напрямую к серверу. Тот же живой интерфейс терминала, функция воспроизведения и инспектор возможностей доступны и в этом режиме.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Earl Bensen
