Коротко: я взял 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-серверов.

Результат оказался интереснее, чем я ожидал.

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

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

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

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

  3. Почему главный вывод оказался не только про 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-подобном сценарии.

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

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

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

Сервер считался успешно обработанным, если:

  • он стартовал;

  • прошёл initialize;

  • отдал список инструментов;

  • по нему был построен scorecard report.

Сервер считался неуспешным, если происходило что-то из следующего:

  • launch failure;

  • timeout на инициализации;

  • missing env/config;

  • сервер писал не-MCP текст в stdout;

  • сломан package entrypoint;

  • сервер требовал интерактивной подготовки.

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

Метрика

Значение

Попыток

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 протокол.

Это критически важный момент. Когда мы видим в реестре "публичный 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:

steps:
  - name: Проверка MCP сервера
    uses: aak204/MCP-Scorecard@v1.0.0
    with:
      cmd: python path/to/your/server.py
      min-score: "80"
      json-out: mcp-scorecard-report.json
      sarif-out: mcp-scorecard-report.sarif

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

Ссылки