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

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

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

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

Распределение 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:

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

Ссылки

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