Разработчик aminzoda представил mcp-linter — утилиту для проверки программ, через которые ИИ получает доступ к файлам и другим инструментам. По его отчёту, проверка трёх официальных эталонных MCP-серверов Anthropic выявила недостающие описания параметров, а у одного сервера — ещё и отсутствие общих инструкций. Это полезный сигнал для тех, кто подключает ИИ к рабочим данным, но не свидетельство взлома.
Что именно проверяет mcp-linter
Model Context Protocol (MCP) задаёт общий способ подключения ИИ к внешним инструментам и данным. MCP-сервер — программа-посредник: она сообщает помощнику, какие действия доступны и какие сведения нужны для их выполнения. Базовое устройство такого подключения разбираем в материале как MCP связывает ИИ с внешними инструментами.
Линтер — это автоматический проверяющий, который ищет нарушения заданных правил. По описанию автора, mcp-linter запускает сервер в дочернем процессе, устанавливает соединение, запрашивает списки инструментов, ресурсов и промптов, применяет 34 правила и завершает процесс. Сами инструменты при такой проверке не вызываются. Это проверка их описаний и обмена сообщениями, а не испытание всех доступных действий.
Автор пишет, что утилита использует только встроенные средства Node.js и не имеет сторонних зависимостей времени выполнения. Результаты она сводит в оценку от 0 до 100. Такая оценка отражает правила конкретного линтера, а не долю безопасных операций сервера.
Что нашлось у трёх серверов
Все результаты ниже приводит разработчик mcp-linter. Эталонный тестовый сервер @modelcontextprotocol/server-everything получил 90/100. Среди 17 инструментов обнаружился параметр resourceType у get-resource-reference без описания.
Сервер памяти @modelcontextprotocol/server-memory получил 66/100. По отчёту, в ответе на инициализацию отсутствовали общие инструкции. Ещё четыре параметра не имели описаний: observations у add_observations, entities у create_entities, relations у create_relations и deletions у delete_observations.
Сервер файловой системы @modelcontextprotocol/server-filesystem получил 38/100: автор насчитал 18 параметров без описаний, в том числе path, content, edits и destination. Для пользователя смысл претензии прост: помощнику нужно понимать, например, какой путь к файлу ожидается и в каком формате передавать содержимое. Одного названия поля для этого может быть недостаточно.
Недочёт описания — ещё не доказанная уязвимость
В статье автор отдельно разбирает более широкий круг рисков: отладочные сообщения могут мешать обмену данными, описания инструментов могут содержать вредоносные указания для модели, а действиям, меняющим данные, нужны понятные предупреждения. Но в приведённых результатах проверки трёх серверов он перечисляет именно пробелы в описаниях и инструкциях. Сообщения об обнаруженной там краже данных или выполнении опасных команд в отчёте нет.
Поэтому низкий балл не стоит читать как сообщение об успешной атаке. И высокий балл не заменяет проверку того, что программа действительно делает с файлами и другими данными: по заявленной методике линтер не вызывает её инструменты. Практический вывод — использовать такой отчёт для разбора конкретных замечаний, а не как универсальный сертификат безопасности.
Что доступно и что пока в планах
Автор представил проект под лицензией MIT с запуском через npx. Режим —fix, по его описанию, генерирует JSON-патчи для аннотаций и недостающих схем. Генерация заплатки сама по себе не означает, что сервер уже исправлен; в случае сервера памяти автор сообщает именно о получении таких заплаток.
Утилита также поддерживает отчёты SARIF v2.1.0 для отображения результатов в GitHub Security. Поддержку удалённых подключений через SSE и WebSocket, подсчёт расхода контекста на схемы и исправление схем с помощью языковой модели разработчик относит к будущим планам. Выдавать эти возможности за уже доступные пока нельзя.
