Инструменты разработчика

сверено с официальной документацией редакции 2026-07-28 4 октября 2026

Вопрос	Чем проверять
отвечает ли сервер, какие у него Tools, Resources и Prompts	MCP Inspector
что именно ушло серверу и что он вернул	MCP Inspector, для HTTP ещё curl
почему сервер завершился или вернул ошибку	журнал сервера
почему сервер не появляется в программе-клиенте	диагностика самого клиента
доходят ли заголовки и события потока через прокси	curl, панель сети в браузере
соответствует ли реализация спецификации	набор тестов соответствия

Состав таблицы взят из руководства «Debugging» официальной документации. В её разделе «Developer tools» всего две темы: Inspector и это руководство.

Inspector - официальная программа, которая подключается к серверу как клиент. Она работает с серверами stdio и Streamable HTTP, вызывает Tools, Prompts и Resources и показывает обмен сообщениями. Руководство по отладке называет её первым шагом.

У программы три интерфейса: страница в браузере, клиент командной строки и интерфейс в терминале. Версии, запуск, порты и настройка эпохи протокола разобраны на отдельной странице «MCP Inspector».

Куда сервер пишет журнал, зависит от транспорта.

stdio. Всё, что сервер пишет в stderr, перехватывает программа, которая его запустила. В stdout локальному серверу писать журнал нельзя: по спецификации stdio сервер не должен выводить туда ничего, кроме сообщений MCP. Посторонняя строка в stdout ломает обмен.

Streamable HTTP. Клиент stderr сервера не видит. Руководство по отладке предлагает собирать журнал на стороне сервера своими средствами или через OpenTelemetry.

OpenTelemetry руководство называет подходящим для всех транспортов.

Журнал через сам протокол (уведомления notifications/message) в редакции 2026-07-28 объявлен устаревшим. В реестре устаревшего замена записана так: писать в stderr на stdio и использовать OpenTelemetry для наблюдения. Подробности - на странице «Что устарело в MCP».

По руководству по отладке большинство клиентов MCP показывает собственный журнал и состояние подключения. Где именно это искать, зависит от клиента: смотрите его документацию.

В качестве примера руководство разбирает Claude Desktop. Что известно о поддержке MCP в отдельных клиентах, собрано в разделе «Клиенты».

Для серверов на Streamable HTTP руководство называет обычные средства HTTP: curl и панель сети в инструментах разработчика браузера. Ими смотрят запросы и потоки SSE.

Что стоит проверять в первую очередь:

• дошли ли до сервера обязательные заголовки MCP-Protocol-Version и Mcp-Method;
• какой статус вернулся: 400, 404 и 405 означают разные ситуации;
• в каком виде пришёл ответ: один объект JSON или поток text/event-stream;
• приходят ли события потока по одному или пачкой после задержки. Второе обычно означает, что ответ накапливает прокси (это наблюдение из практики, не правило MCP).

Образцы запросов для curl есть на странице «Сервер для двух эпох». Заголовки и статусы описаны в разделе «Транспорты», поведение прокси - на странице «Streamable HTTP и переход с HTTP+SSE».

В организации modelcontextprotocol на GitHub есть репозиторий conformance. Его README называет проект так: каркас для проверки реализаций клиента и сервера MCP на соответствие спецификации. Там же сказано, что для авторов SDK есть отдельное руководство по подключению тестов.

Страница уровней SDK сообщает, что все SDK оцениваются этими автоматическими тестами.

Последний выпуск набора на GitHub - v0.1.16 от 27 марта 2026. Работа в основной ветке продолжалась и позже: последняя отправка изменений в репозиторий датирована 1 октября 2026.

• Tools как часть протокола - это отдельная страница.
• SDK для написания серверов и клиентов - это раздел «SDK».
• Сторонние программы отладки. Здесь перечислено только то, что называет официальная документация.

• MCP Inspector - запуск, порты, выбор эпохи, известные ограничения выпуска.
• Решение проблем - типовые сбои и их причины.
• Транспорты - заголовки и статусы, которые видны в curl.