Коротко: я взял 30 публичных MCP-серверов, попытался прогнать их через детерминированный CI-сканер и быстро понял одну вещь. Рискованные инструменты - это полбеды. Главная боль экосистемы кроется в банальной launchability: часть серверов просто не стартует в headless-режиме, требует скрытую конфигурацию или ломает протокол мусором в stdout.

Сейчас MCP-серверы стали для LLM-агентов тем же, чем когда-то были обычные пакеты и API-интеграции для разработчиков: стандартным способом дать модели доступ к внешнему миру.

На практике это выглядит просто: находим сервер в реестре, подключаем его к Cline, Roo Code, Codex или другому клиенту - и ожидаем, что всё заработает само. Но довольно часто вместо магии происходит следующее:

• агент зависает на инициализации;

• инструмент стартует, но потом падает из‑за кривой схемы;

• сервер пишет в stdout лишний текст и ломает JSON‑RPC;

• модель начинает галлюцинировать аргументами, потому что входная схема описана слишком слабо;

• в процесс внезапно утекает высокий blast radius: файловая система, сетевые вызовы, команды оболочки.

Честно говоря, пока я парсил эти серверы и ловил ошибки на ровном месте, у меня знатно сгорело. Я ожидал увидеть секьюрные инструменты, а получил зоопарк из костылей. В какой-то момент стало очевидно: экосистеме отчаянно не хватает базового детерминированного слоя проверки. Того, что можно прогонять локально и в CI до попадания MCP-сервера в реальные агентные сценарии.

Так появился MCP Scorecard - детерминированный CI-first сканер качества серверов. Чтобы проверить его в боевых условиях, я прогнал через него 30 публичных проектов. Результат оказался интереснее, чем я ожидал.

О чём эта статья

В статье я хочу показать три вещи:

1. Что именно я проверял и почему отказался от подхода LLM-as-a-judge.

2. Что получилось на выборке из 30 публичных MCP-серверов.

3. Почему главный вывод касается именно готовности серверов к запуску (launchability).

В конце покажу сам инструмент и объясню его реальные юзкейсы.

Что такое MCP Scorecard

Это детерминированный сканер. Он делает простую, но важную работу:

• запускает MCP-сервер локально через stdio;

• проходит initialize;

• получает tools/list;

• прогоняет доступную инструментальную поверхность через набор проверок;

• считает score;

• сохраняет результат (terminal summary, JSON report, SARIF, GitHub Actions summary).

Что именно оценивается (4 метрики):

• Соблюдение протокола: правильность схем и целостность базового контракта общения.

• Безопасность: наличие откровенно опасных доступов (консоль, удаление файлов, сеть).

• Удобство для ИИ: качество описания аргументов, снижающее риск галлюцинаций модели.

• Заполнение метаданных: наличие вменяемых названий и описаний у функций.

Почему не LLM‑as‑a-judge

Здесь мы оцениваем грубые, математически проверяемые факты, от которых зависит стабильность системы, без субъективщины в духе «какой ответ выглядит красивее».

Инструменту нужно жестко отловить слабые схемы типизации и запретить передачу произвольных параметров. Он должен подсвечивать очевидные дыры: торчащий наружу доступ к записи файлов или скрытые критически важные поля. Плюс сканер банально проверяет, вываливает ли сервер отладочный мусор в stdout. По своей архитектуре это классический строгий линтер. Никаких нейросетей-оценщиков с их предвзятостью.

Как я собирал тестовую выборку

В тестирование попали 30 публичных MCP-серверов из разных категорий:

• 4 официальных reference-сервера от modelcontextprotocol;

• 26 публичных серверов из реестра и смежных источников.

У этого прогона были жёсткие условия: только stdio-серверы, строго headless запуск, никаких API-ключей, ручной настройки и интерактивной авторизации (запуск best-effort на Windows через npx.cmd).

Моей целью было проверить узкую, но критичную вещь: насколько публичный MCP-сервер готов к слепому воспроизводимому запуску в CI-подобном сценарии.

Как оценивался результат

Для каждого сервера сценарий был идентичным:

mcp-scorecard scan --json-out <report.json> --cmd <server command>

Успешным считался сервер, который стартовал, прошёл инициализацию, отдал список инструментов и позволил построить scorecard report. Любые тайм-ауты, ошибки окружения, мусор в логах или требования интерактивности автоматически отправляли проект в категорию неуспешных.

Краткие итоги сканирования

Распределение score по успешным

Вывод

Самая частая детерминированная проблема среди успешно просканированных серверов: weak_input_schema - 7 серверов

1. Success vs Failure

2. Score distribution

3. Failure reasons

Инсайт 1. У MCP сейчас есть проблема launchability

Самое неприятное открытие ждало меня еще до подсчета баллов. Из 30 серверов только 16 дошли до стадии скоринга. Почти половина отвалилась на старте из-за скрытых конфигураций, незадокументированных переменных окружения или тайм-аутов. Самая абсурдная ошибка - успешный старт пакета с последующим выводом приветственного текста прямо в stdout, что намертво ломает JSON-RPC.

Наличие сервера в реестре совершенно не гарантирует его готовность к работе в конвейере.

Оценку необходимо жестко разделять на два слоя. Первый - Layer 0 (Preflight / Launchability): базовая жизнеспособность без "ручной магии". И только те, кто выжил, допускаются на Layer 1 (Scorecard / Reviewability) для аудита схем, эргономики и безопасности. Иначе массовое слепое сканирование теряет смысл.

Инсайт 2. Даже у «живых» серверов часто слабая инструментальная поверхность

Среди успешно стартовавших проектов доминирует проблема качества схем (weak_input_schema).

Входная поверхность описывается слишком слабо: нет типизации, разрешены свободные поля, отсутствуют required параметры. Человек догадается, как это использовать, а LLM начнет достраивать аргументы по вероятности. Результат: неправильный вызов, ошибка, ретраи и сожженные токены. Для агентного стека слабая схема бьет напрямую по бюджету и надежности.

Инсайт 3. Низкий score не всегда означает «плохой сервер»

Показательный кейс с официальными инструментами:

• @modelcontextprotocol/server-memory → 100/100

• @modelcontextprotocol/server-filesystem → 40/100

40 баллов у файлового сервера - это нормальное поведение. Просто его инструментальная поверхность (create_directory, edit_file, write_file) изначально несет огромные риски для автономного исполнения.

Здесь нет деления на «хорошие» и «плохие» инструменты. Важно лишь то, какую свободу вы даете агенту в рамках workflow. Низкий балл заставляет инженера осознанно подходить к рискам. MCP Scorecard абстрагируется от бизнес-логики и измеряет проверяемую поверхность доступа.

Инсайт 4. Публичный реестр полезен для поиска, но не гарантирует воспроизводимый запуск

Официальный каталог отлично справляется с задачей обнаружения (discovery). Однако на практике заявленные как no-env проекты падали без скрытой конфигурации, а корректно установленные бинарники спамили в консоль. Это естественный признак молодой экосистемы.

Главный вывод прогона

MCP Scorecard эффективен как инструмент детерминированного аудита, но только для пакетов, способных чисто стартовать и ответить на базовые запросы (initialize и tools/list). Массовое сканирование упирается в проблему «предполетной подготовки». Понимание этой механики куда полезнее для индустрии, чем очередной топ-10 плагинов.

Что я бы делал дальше

План развития довольно прозрачен:

1. Выделить стадию preflight для классификации ошибок запуска (интерактивность, сломанный пакет, тайм-ауты).

2. Четко разделить в отчетах проблемы запуска (launch failures) и итоговые баллы (score).

3. Публиковать результаты аудита экосистемы как воспроизводимый датасет.

Заключение

У MCP сейчас классическая фаза взросления. Стандарт, инструменты и реестр есть, интерес огромный. Но нормальная инженерная дисциплина (аудит поверхности, гигиена схем, воспроизводимый запуск без ручной доработки) только формируется.

Здесь нужен скучный, воспроизводимый слой инфраструктуры, без магии «умных AI-платформ». Сборка из 30 серверов показала главное: проблема хаоса реальна, а детерминированный тулинг уже перестал быть просто игрушкой.

Ссылки

• Репозиторий: MCP Scorecard