Коротко: я взял 30 публичных MCP-серверов, попытался прогнать их через детерминированный CI-сканер и довольно быстро понял, что проблема экосистемы — не только в рискованных тулзах, но и в банальной launchability: часть серверов не стартует в headless-режиме, часть требует скрытую конфигурацию, часть ломает протокол мусором в stdout.
Сейчас MCP-серверы стали для LLM-агентов тем же, чем когда-то были обычные пакеты и API-интеграции для разработчиков — стандартный способ дать модели доступ к инструментам, данным и внешним действиям.
На практике это выглядит просто: мы видим сервер в реестре, подключаем его к Cline, Roo Code, Codex или другому клиенту — и ожидаем, что дальше всё заработает само.
Но довольно часто вместо этого происходит что-то из следующего:
- агент зависает на инициализации;
- инструмент стартует, но потом падает из-за кривой схемы;
- сервер пишет в stdout лишний текст и ломает JSON-RPC;
- модель начинает галлюцинировать аргументами, потому что входная схема описана слишком слабо;
- в процесс внезапно утекает высокий blast radius: файловая система, сетевые вызовы, команды оболочки.
В какой-то момент я понял, что у экосистемы не хватает очень базовой вещи — детерминированного слоя первичной проверки, который можно прогонять локально и в CI до того, как MCP-сервер попадёт в реальные агентные сценарии.
Так появился мой инструмент — MCP Scorecard: детерминированный CI-first сканер качества MCP-серверов. А чтобы проверить, не является ли он просто красивой демкой на одном тестовом fixture, я прогнал через него 30 публичных MCP-серверов.
Результат оказался интереснее, чем я ожидал.
О чём эта статья
В статье я хочу показать три вещи:
- Что именно я проверял и почему решил не использовать LLM-as-a-judge.
- Что получилось на batch из 30 публичных MCP-серверов.
- Почему главный вывод оказался не только про security, но и про launchability.
А в конце покажу сам инструмент и объясню, где он реально полезен, а где пока нет.
Что такое MCP Scorecard
MCP Scorecard — это детерминированный сканер для MCP-серверов.
Он делает довольно простую, но важную работу:
- запускает MCP-сервер локально через stdio;
- проходит initialize;
- получает tools/list;
- прогоняет доступную инструментальную поверхность через набор проверок;
- считает score;
- сохраняет результат в: terminal summary, JSON report, SARIF, GitHub Actions summary.
Что именно оценивается
Сейчас у MCP Scorecard четыре метрики:
- Соблюдение протокола: правильно ли написаны схемы и не ломается ли базовый контракт общения (без душной полной сертификации).
- Безопасность: не даёт ли сервер языковой модели гранату в руки (доступ к консоли, удалению файлов или сети).
- Удобство для ИИ: насколько понятно описаны аргументы, чтобы модель не галлюцинировала и не пыталась угадывать параметры вслепую.
- Заполнение метаданных: есть ли у функций названия и описания, пригодные для машинной обработки.
Почему не LLM-as-a-judge
Я сознательно отказался от популярного сейчас подхода LLM-as-a-judge. В нашем случае речь идёт не о субъективных материях вроде того, «какой ответ выглядит красивее», а о грубых, математически проверяемых фактах, от которых зависит стабильность системы.
Инструменту нужно жестко отловить слабые схемы типизации и запретить передачу произвольных параметров, из-за которых модель начинает фантазировать. Он должен автоматически подсвечивать очевидные дыры: торчащий наружу доступ к записи файлов, возможность делать произвольные сетевые запросы или скрытые критически важные поля. Наконец, сканер банально проверяет, не вываливает ли сервер отладочный мусор в stdout, разрушая тем самым чистый контракт общения по протоколу. По своей архитектуре это классический строгий линтер, а не нейросеть-оценщик с её неизбежной предвзятостью и галлюцинациями.
Как я собирал тестовую выборку
Я взял 30 публичных MCP-серверов из разных категорий и разных разработчиков:
- 4 официальных reference server’а от modelcontextprotocol;
- 26 публичных серверов из реестра и смежных источников.
Ограничения выборки
Сразу важный дисклеймер: это не рейтинг всей MCP-экосистемы. У этого прогона были жёсткие условия:
- только stdio-серверы;
- только headless запуск;
- без API-ключей;
- без ручной настройки;
- без интерактивной авторизации;
- запуск best-effort на Windows через npx.cmd.
Это значит, что я проверял не «абсолютное качество всех MCP-серверов на свете», а более узкую вещь:
насколько публичный MCP-сервер готов к слепому reproducible запуску и первичному review в CI-подобном сценарии.
Как оценивался результат
Для каждого сервера сценарий был один и тот же:
Сервер считался успешно обработанным, если:
- он стартовал;
- прошёл initialize;
- отдал список инструментов;
- по нему был построен scorecard report.
Сервер считался неуспешным, если происходило что-то из следующего:
- launch failure;
- timeout на инициализации;
- missing env/config;
- сервер писал не-MCP текст в stdout;
- сломан package entrypoint;
- сервер требовал интерактивной подготовки.
Краткие итоги сканирования
Успешных сканов
Fail на launch/init
Success rate
No-env серверов
Успешных среди no-env
Env-required серверов
Успешных без секретов
Средний score по успешным
Распределение score по успешным
Количество серверов
Самая частая детерминированная проблема среди успешно просканированных серверов:
- weak_input_schema — 7 серверов
1. Success vs Failure
2. Score distribution
3. Failure reasons
Инсайт 1. У MCP сейчас есть проблема launchability
Самое неприятное открытие ждало меня ещё до подсчёта баллов. Из 30 серверов только 16 вообще дошли до стадии скоринга. Почти половина отвалилась на старте из-за банальных проблем: скрытых конфигураций, не задокументированных переменных окружения, тайм-аутов инициализации или просто кривой упаковки. Самая абсурдная и частая ошибка — когда сервер успешно стартует, но выводит приветственный текст прямо в stdout, намертво ломая JSON-RPC протокол.
Это критически важный момент. Когда мы видим в реестре «публичный MCP-сервер», это совершенно не гарантирует, что он готов к работе в CI-конвейере или способен запуститься в headless-режиме без «ручной магии» со стороны пользователя.
Именно поэтому я пришёл к главному архитектурному выводу всего исследования: оценку серверов необходимо жестко разделять на два слоя. Первый — это Layer 0 (Preflight / Launchability), где мы проверяем базовую жизнеспособность: стартует ли сервер, проходит ли инициализацию, не мусорит ли в stdout и не требует ли скрытой настройки. И только те, кто выжил на нулевом слое, допускаются на Layer 1 (Scorecard / Reviewability), где мы уже оцениваем качество схем, эргономику, метаданные и риски безопасности. Без такого разделения любое массовое слепое сканирование теряет смысл.
Инсайт 2. Даже у «живых» серверов часто слабая инструментальная поверхность
Когда убрать тех, кто не стартует вообще, оказывается, что следующая массовая проблема — это качество схем.
Самая частая причина в успешной группе — weak_input_schema.
На практике это значит, что сервер формально работает, но его входная поверхность описана слишком слабо:
- нет достаточной типизации;
- разрешены слишком свободные поля;
- не хватает required;
- вход выглядит недоопределённым для надёжного агентного вызова.
Почему это бьёт именно по агентам
Человек ещё может догадаться, что хотел автор API. LLM в таком месте начинает достраивать аргументы по вероятности.
Результат знакомый:
- неправильный вызов;
- ошибка сервера;
- ретрай;
- ещё один ретрай;
- токены и время улетают в пустоту.
То есть слабая схема — это не «косметический минус». Для агентного стека это прямой удар по надёжности и стоимости.
Инсайт 3. Низкий score не всегда означает «плохой сервер»
Самый показательный кейс — официальный сервер:
- @modelcontextprotocol/server-memory → 100/100
- @modelcontextprotocol/server-filesystem → 40/100
На первый взгляд хочется сказать: «ну вот, filesystem плохой». Но это было бы неверно.
Что на самом деле означает 40/100 у filesystem server
Это не баг и не обвинение в том, что сервер написан плохо. Это сигнал о том, что его инструментальная поверхность по определению рискованна для автономного агентного исполнения.
Например, scorecard закономерно подсвечивает такие вещи, как:
- create_directory
- edit_file
- write_file
То есть вопрос не в том, «хороший» это сервер или «плохой». Вопрос в том, какую ты даёшь свободу агенту, когда подключаешь этот сервер в реальный workflow.
И в этом смысле низкий score полезен: он заставляет не перепутать «легитимный use case» с «безопасной поверхностью по умолчанию».
Это важный момент
MCP Scorecard не оценивает бизнес-логику. Он измеряет проверяемую поверхность риска. Это ровно то, что должен видеть инженер, когда подключает инструмент к агенту.
Инсайт 4. Публичный реестр полезен для поиска, но не гарантирует воспроизводимый запуск
Официальный каталог отлично справляется с задачей обнаружения (discovery) новых серверов. Однако наше массовое сканирование быстро показало: найти проект и честно запустить его в автоматическом режиме — это две совершенно разные задачи.
Что выяснилось на практике:
- некоторые проекты заявлялись как не требующие настройки, но по факту падали без скрытой конфигурации при запуске;
- часть пакетов имела корректные исполняемые файлы, но всё равно выводила приветственный или отладочный текст в stdout (намертво ломая тем самым JSON-RPC протокол);
- многие серверы успешно устанавливались, но оказались абсолютно не готовы к автоматическому запуску в CI-конвейере вслепую.
В этом нет вины конкретных авторов. Это естественный признак молодой и ещё не устоявшейся экосистемы.
Самый полезный вывод из всего эксперимента
Главный итог прогона для меня звучит так:
MCP Scorecard доказал свою эффективность как строгий инструмент детерминированного аудита. Но он работает только для тех серверов, которые действительно способны чисто стартовать и корректно ответить на базовые запросы протокола (initialize и tools/list).
Стало очевидно, что массовое автоматическое сканирование публичных проектов — это не только задача оценки качества (скоринга). Это в первую очередь проблема «предполётной подготовки» и банальной готовности пакетов к автономному запуску.
И этот инсайт, на мой взгляд, куда честнее и полезнее для индустрии, чем публикация банального списка «топ-10 лучших и худших MCP-серверов».
Что такое MCP Scorecard на практике
Сейчас инструмент полезен в трёх сценариях:
1. Локальный pre-adoption review
Перед тем как подключать сервер к агенту, можно быстро посмотреть:
- что он вообще открывает наружу;
- насколько понятны схемы;
- есть ли опасные capability surfaces.
2. CI gate
Если вы публикуете собственный MCP-сервер, можно добавить score threshold в CI:
3. Reproducible review artifact
На выходе остаются:
- terminal summary;
- JSON report;
- SARIF;
- GitHub Actions summary.
Это удобно не только для «прошёл / не прошёл», но и для диффов между релизами.
Что я бы делал дальше
Следующий логичный шаг уже понятен.
1. Добавить preflight stage
Чтобы разделять:
- launchable
- requires_auth
- interactive
- broken packaging
- non-MCP stdout
- init_timeout
2. Не смешивать launch failures со score
Отчёт должен чётко разделять:
- кто вообще дошёл до scoring;
- кто не дошёл и почему.
3. Публиковать результаты как reproducible dataset, а не как «чёрный список»
Это очень важно для доверия.
Заключение
Мне кажется, у MCP сейчас очень знакомая фаза взросления.
Стандарт уже появился. Инструменты уже появляются. Реестр уже появился. Интерес огромный.
Но вокруг этого ещё не сформировалась нормальная инженерная дисциплина:
- как проверять server surface;
- как оценивать schema hygiene;
- как отделять легитимный риск от небрежной упаковки;
- как reproducibly запускать чужие серверы без ручной магии.
И именно здесь deterministic tooling начинает быть полезным.
Не как «умная AI-платформа», а как скучный, воспроизводимый, reviewable слой инфраструктуры.
Для меня сборка из 30 серверов была полезна ровно этим: она показала, что проблема реальна, а сам инструмент уже не выглядит игрушкой.