MCP CLI проверяет инструменты сервера через командный вызов Inspector: сначала получает tools/list, затем запускает разрешённый read-only инструмент на синтетической записи. JSON-результат и код завершения помогают встроить такой smoke-test в CI. Проверка показывает поведение тестового экземпляра; решение о правах и подтверждении вызова остаётся за сервером.
Задача проверки
MCP Inspector CLI позволяет из командной строки запросить tools/list, вызвать разрешённый тестовый инструмент через tools/call и получить машинно читаемый JSON. Код завершения помогает отличить успешный smoke-test от ошибки подключения, авторизации или инструмента.
Запрос «mcp cli» для команды разработчиков означает короткую проверку сервера без ручного обхода экранов клиента. После изменения серверного кода важно убедиться, что клиент видит нужный инструмент, его схема читается и безопасный вызов возвращает ожидаемый тип результата. Здесь речь о маршруте проверки через консоль и CI. Состав функций сервера и правила их описания отдельно разбирает материал про инструменты MCP.
Официальный README Inspector CLI показывает запуск через npx @modelcontextprotocol/inspector --cli и методы tools/list, tools/call. Команда подключается к серверу, выполняет выбранный метод и завершает соединение. Для автоматического разбора флаг --format json выдаёт единый JSON-объект на стандартный вывод. Поэтому проверку можно включить в отдельный шаг сборки с заранее подготовленным тестовым сервером.
Этот путь подтверждает наблюдаемое поведение конкретного экземпляра. Список инструментов зависит от полномочий вызывающего клиента. Право выполнить действие требует отдельной серверной проверки. Последующее решение о доступе принимает сервер по своей политике. Языковая модель может помочь объяснить очищенный результат проверки, но доступ и подтверждение всегда остаются в коде приложения и на стороне сервера.
Тестовый сервер
Для будущего пилота выделите тестовый сервер с одним инструментом чтения фикстуры. В статье условное имя такого инструмента — read_fixture; его требуется реализовать в собственном тестовом сервере. Инструмент принимает обезличенный идентификатор записи и возвращает подготовленный текст. У него отсутствуют операции записи, отправки сообщений и обращения к рабочим данным. Команды ниже служат шаблоном для уже собранного локального сервера по пути ./test-server/build/index.js.
- Подготовьте отдельный набор синтетических данных и учётную запись с правом чтения. Убедитесь, что инструмент read_fixture опубликован в тестовом каталоге сервера.
- Запросите список:
npx @modelcontextprotocol/inspector --cli node ./test-server/build/index.js --method tools/list --format json. В полученном JSON найдите имя read_fixture и его inputSchema. - Вызовите только чтение:
npx @modelcontextprotocol/inspector --cli node ./test-server/build/index.js --method tools/call --tool-name read_fixture --tool-args-json '{"id":"sample"}' --format json. Значение sample относится к синтетической фикстуре. - Сохраните код завершения каждого запуска и очищенный JSON-результат. Разделяйте сбой подключения, отказ доступа и ошибку самого инструмента.
Флаг --tool-args-json передаёт объект аргументов без преобразования значений из строк вида key=value. Это полезно, когда тип поля важен для входной схемы. Имя инструмента и ключ id в примере принадлежат условному тестовому контракту; в реальном проекте их берут из tools/list. Для такого вызова выбирают только согласованный тестовый инструмент: название метода само по себе скрывает возможные побочные эффекты.
Inspector CLI запускает локальную команду сервера в примере с node. Перед включением в CI команда разработки фиксирует источник тестового пакета и рабочий каталог. Запуск сервера с доступом к производственным секретам ломает смысл изолированной проверки. Для удалённого сервера README описывает отдельный HTTP-маршрут, однако в этом сценарии достаточно локального тестового процесса без внешнего доступа.
Разбор результата
После tools/list проверьте наличие требуемого имени и структуру inputSchema. Схема должна соответствовать ожидаемому контракту тестового инструмента: объект аргументов, известные поля и необходимые ограничения. После tools/call разберите обёртку CLI и сам результат метода. По официальному README режим --format json размещает ответ под ключом result. Точное содержимое этого объекта задаёт тестовый сервер; в статье приведена команда без вымышленного вывода.
| Наблюдение | Вывод для проверки | Следующий шаг |
|---|---|---|
| Инструмента нет в списке | Сверить публикацию и права перечисления | Проверить конфигурацию тестового сервера |
| Схема расходится с эталоном | Контракт аргументов изменился | Сравнить inputSchema с ожидаемой версией |
| Вызов вернул isError | Ошибка выполнения инструмента | Изучить очищенный серверный журнал |
| CLI завершился с ошибкой доступа | Запрос отклонён по полномочиям | Проверить тестовую роль на сервере |
| Код завершения успешный | Метод отработал на тестовом входе | Сверить содержимое result с эталоном |
Разделяйте ошибку протокола и ошибку содержимого. Спецификация инструментов MCP описывает ответ на вызов и признак isError для ошибки инструмента. Inspector CLI документирует отдельный код завершения для результата isError:true. Совпадение успешного ответа с ожидаемой фикстурой скрипт проверяет отдельно по заранее записанному эталону.
Чтобы объяснить сложный отказ, передавайте языковой модели только очищенную трассу: метод, тип ошибки и разрешённые диагностические поля. Парсер проверяет полный JSON и типы аргументов, модель предлагает гипотезы, разработчик сверяет их с ответом сервера и журналом. Для диагностики конверта JSON-RPC полезен отдельный разбор структуры сообщения; этот smoke-test сосредоточен на рабочем маршруте Inspector CLI.
Хотите проверить свой MCP-сервер через безопасный CLI-сценарий?
Проверка в CI
В CI удобно разделить проверку каталога и вызов фикстуры на самостоятельные команды. Скрипт сначала получает JSON-список, сверяет имя инструмента и требуемые поля схемы, затем отправляет тестовый аргумент. Для каждого запуска он сохраняет код завершения и очищенный результат. Если первый шаг провалился, вызов прекращается: отсутствие инструмента уже даёт конкретный сигнал для владельца серверного контракта.
README Inspector CLI описывает коды завершения как классы причин: успех, ошибка синтаксиса команды, запрос авторизации, недоступность сервера, ошибка инструмента и проблема переносимости схемы. Точные значения проверяйте по закреплённой версии пакета перед настройкой условий сборки. В частности, результат isError:true может быть напечатан в JSON, но CLI всё равно завершится с ошибкой инструмента. Поэтому обработчик анализирует и код процесса, и поле результата.
При проверке переносимости схемы можно добавить --strict к tools/list. Официальный README прямо поясняет границу этой проверки: она ищет проблемы совместимости схем с клиентами. Полную проверку JSON Schema выполняет отдельный валидатор. Предупреждения и ошибки такого анализа имеют разные последствия для кода завершения. Для собственных обязательных правил команды нужен отдельный валидатор схемы и контроль ожидаемой структуры результата.
- Проверка запуска: тестовый процесс доступен, а CLI получает ответ метода.
- Проверка контракта: имя и входная схема инструмента совпадают с утверждённым эталоном.
- Проверка действия: read_fixture читает только синтетическую запись, результат соответствует ожиданию.
- Проверка отказа: сервер отклоняет вызов от субъекта без нужного права.
- Проверка следа: журнал сборки содержит статус, очищенный результат и ссылку на исправление.
Секреты доступа и содержимое рабочих документов исключают из командной строки и артефактов сборки. Для удалённого сервера политика авторизации и способ передачи учётных данных требуют отдельного решения владельца среды. Публикация JSON-результата в открытом логе может раскрыть возвращённые данные даже при успешном коде выхода. Хранение артефакта ограничивают правилами команды и типом тестовой фикстуры.
Критерии приёмки
Предложение для пилота — пройти один и тот же набор проверок на изолированном тестовом сервере после изменения описания инструмента. Владелец сервера заранее согласует эталон схемы, разрешённую фикстуру, ожидаемый ответ и признаки отказа. Разработчик клиента проверяет форму JSON и код завершения; специалист по доступу подтверждает, что сервер отклоняет запрещённый вызов. Такая схема даёт понятную передачу результата между участниками команды.
Приёмка состоит из наблюдаемых условий. Каталог возвращает нужное имя и схему. Разрешённый вызов чтения завершается с ожидаемым содержимым. Неверный аргумент приводит к контролируемому отказу. Субъект без полномочия получает отказ сервера. Очищенная трасса позволяет связать каждый запуск с ожидаемым исходом. Для каждого отклонения команда фиксирует владельца исправления и повторяет ровно соответствующий тест.
Маршрут подключения других клиентов изложен в обзоре MCP-клиентов, а проектирование собственного сервера — в материале о серверных инструментах. Здесь решение ограничено CLI smoke-test и доказуемым результатом отдельного вызова. Если компании нужен общий контур разработки, согласования прав и приёмки инструментов, обсудить его можно в рамках внедрения ИИ-агентов.
Затраты на пилот зависят от выбранного размещения, требований к журналу и числа проверяемых инструментов. Условия используемых сервисов сверяют по актуальной документации перед согласованием бюджета. Расширение тестов имеет смысл после проверки базового маршрута чтения и отказа: каждая новая операция получает собственный эталон входа, ожидаемый результат и серверное правило доступа.