Обновить

Как я индексировал экосистему MCP: 9 источников, 80 000 серверов и куча нюансов

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели5.4K
Всего голосов 1: ↑1 и ↓0+3
Комментарии7

Комментарии 7

неудобный сайт - допустим я хочу посмотреть какие у вас есть mcp по дизайну в целом (не знаю названия нужного mcp).

...почти 1700 mcp вы предлагаете скроллить вручную с подгрузкой следующей страницы. И это не говоря уже о ситуации, если вдруг потребуется искать среди всех ~83к mcp. Почему не разбить на просто страницы с переключением через номера? Почему например, не добавить сортировку по дате добавления/обновления на сайте?

Справедливо, принято. Мы сейчас как раз в процессе переработки UI/UX каталога, и навигация по большим спискам там главный пункт: сортировка по дате добавления и обновления, нормальная работа с тысячами карточек вместо бесконечного скролла, фильтры внутри категорий.

Пока это едет, для вашего сценария «посмотреть mcp по дизайну, не зная названий» лучше заходить не через общий список: на unyly.org/categories дизайн лежит отдельной полкой и внутри отсортирован по установкам, самое рабочее сверху. А свежедобавленное живёт на unyly.org/new, это как раз по дате.

Спасибо за конкретику, такой фидбек полезнее лайков - часть пунктов ровно в таком виде и уедет в редизайн.

Апдейт: сортировку уже добавили — в /browse теперь переключатель «По установкам / Новые / По рейтингу / По имени», без перезагрузки страницы. Новые = по дате релиза пакета. Пользуйтесь)

спасибо. Я там еще нашел ошибки в данных:

  • некоторые mcp имеют только название (нет репозитория, инструкции и т.п.)

Скрытый текст
  • некоторые mcp в неправильных разделах. Например, "Archivebox API" считается Design

Спасибо! Приняли в работу.

круто, а шлюз это по сути централизованная точка доступа к каталогу - не боишься что агенты начнут слать запросы ко всем серверам подряд и это создаст нагрузку на сами серверы?

Хороший вопрос, но тут спасает деталь архитектуры: шлюз не бродкастит запросы по серверам вообще.

search_mcps ищет по нашему индексу, это запрос в нашу базу, ни один из 83k серверов при поиске не трогается. Дальше агент делает use_mcp_tool уже по конкретному серверу, который выбрал. То есть нагрузка на сторонний сервер возникает только при явном целевом вызове, ровно так же, как если бы юзер поставил этот сервер локально и дёрнул инструмент руками.

Плюс всё это за OAuth-токеном с метерингом: вызовы считаются per-token, есть лимиты, так что даже сошедший с ума агент упрётся в потолок раньше, чем создаст кому-то заметную нагрузку. Единственное, что мы сами регулярно делаем к чужим серверам, это health-check раз в час: один лёгкий initialize, чтобы каталог не показывал мёртвые эндпоинты.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации