Коротко: я взял 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 публичных проектов. Результат оказался интереснее, чем я ожидал.

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

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

Что именно я проверял и почему отказался от подхода LLM-as-a-judge.
Что получилось на выборке из 30 публичных MCP-серверов.
Почему главный вывод касается именно готовности серверов к запуску (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. Любые тайм-ауты, ошибки окружения, мусор в логах или требования интерактивности автоматически отправляли проект в категорию неуспешных.

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

Метрика	Значение
Попыток	30
Успешных сканов	16
Fail на launch/init	14
Success rate	53.3%
No-env серверов	19
Успешных среди no-env	12
Env-required серверов	11
Успешных без секретов	4
Средний score по успешным	88.75

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

Score	Количество серверов
100/100	7
90/100	7
50/100	1
40/100	1

Вывод

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

1. Success vs Failure

Рис. 1. Почти половина серверов не дошла даже до скоринга в headless best-effort сценарии. — **Рис. 1.** Почти половина серверов не дошла даже до скоринга в headless best-effort сценарии.

2. Score distribution

Рис. 2. Среди серверов, которые вообще запустились, большая часть выглядела приемлемо. — **Рис. 2.** Среди серверов, которые вообще запустились, большая часть выглядела приемлемо.

3. Failure reasons

Рис. 3. Проблема публичного batch-scanning - это не только score, но и launchability. — **Рис. 3.** Проблема публичного batch-scanning - это не только score, но и launchability.

Инсайт 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 плагинов.

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

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

Выделить стадию preflight для классификации ошибок запуска (интерактивность, сломанный пакет, тайм-ауты).
Четко разделить в отчетах проблемы запуска (launch failures) и итоговые баллы (score).
Публиковать результаты аудита экосистемы как воспроизводимый датасет.

Заключение

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

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

Ссылки

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

Я просканировал 30 публичных MCP-серверов: почти половина не дошла даже до скоринга