Блог
Руководства

Двунаправленный MCP: маркетплейс и открытый RAG

Как Simmetric Chat говорит на MCP в обе стороны - внешние MCP-серверы с маркетплейса становятся skill'ами агента, а встроенный сервер открывает RAG-поиск workspace'а IDE - с запасным транспортом, проверками здоровья и пиннингом на чат.

Simmetric Team8 мин чтения15/10/2026
Двунаправленный MCP: маркетплейс и открытый RAG

Ассистент, встречающий инструменты на полпути MCP имеет два направления, и большинство интеграций рассказывает лишь об одном

MCP has two directions, and most integrations tell only about one. В направлении connect вы приносите ВНЕШНИЕ MCP-серверы в workspace, и их инструменты становятся вызываемыми в чатах - без кода, без переустановки. В направлении expose Simmetric Chat выворачивается наизнанку: встроенный MCP-сервер отдаёт RAG-поиск workspace'а внешним клиентам - вашим IDE, где ваши разработчики и работают.

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

Письменные руки маркетплейса - админские (гулять хватит авторизоваться). Факты: FACT-CENSUS.md F-MCP-1.

Направление connect: маркетплейс

MCP Marketplace - кураторский каталог внешних MCP-серверов. Гулять по каталогу (список + деталь) хватит аутентификации; руки записи - заводить записи и ставить в workspace - только админу. Поток установки атомарен и авто-замкнут:

  1. Схема валидирует payload установки (workspace + опциональная накладка имени/заголовков - заголовки проходят письменную проверку блок-листом, что отбрасывает hop-by-hop ключи, требует regex имён, и теснит размеры).
  2. Запись должна существовать (404) и не быть уже установленной в том workspace (409).
  3. Строка подключения, скоупнутого на workspace, рождается с URL и транспортом каталога.
  4. Событие приземляется в журнал аудита (mcp.installed), и коннектор пускается fire-and-forget: провал соединения записывается, никогда не глотается в «здоровое» состояние.

Деустановка - обратное: регистрации инструментов падают, подключение жёстко стирается, и строка аудита приземляется (mcp.uninstalled). Установка потому возвратна без остатка.

Внешние инструменты становятся skill'ами агента

Соединённый инструмент каждого внешнего сервера регистрируется вskill-реестре агента под без-коллизионными именами (mcp_<подключение>_<инструмент>). Реестр решается на каждый чат:

  • Без пинов - всякое активное подключение workspace'а одалживает свои инструменты.
  • С пинами - только запиннутые И включённые И в скоупе; пиннабор никогда не может ЗАБРАТЬ инструменты (он лишь добавляет - строгое объединение со скоупнутыми на workspace инструментами стоит).

Пиннинг на чат - руль операции: комплаенс-чат говорит с точными инструментами, какими должен - не трогая остальное workspace'а.

Направление expose: IDE дотягивается до RAG

Встроенный MCP-сервер открывает retrieval платформы внешним клиентам:

  • `rag_query` - ищет в документах workspace'а (обоснованный, цитируемый поиск, которым ходит внутренний чат).
  • `list_workspaces` - открыательный рука клиентской стороны.

Транспорт - stateless Streamable-HTTP-эндпойнт (актуальная core-ревизия MCP, ответы только-JSON); легаси-SSE-транспорт остаётся с окном на уход. У аутентификации две формы: при заданном MCP_API_KEY - bearer-проверка (нет или неверна = 401); без - сервер отступает только-на-loopback - удалённые вызывающие получают 401, а не неаутентифицированный доступ. История IDE: редактор разработчика достаёт ту же обоснованную документную поиск, что и чат - база знаний - один корпус со многими дверями.

Операционные рельсы

Три механизма держат оба направления управляемыми, а не только включёнными:

  • Запасной транспорт - соединение, объявленное streamable, отступает в SSE при 4xx-отказе (никогда при 5xx - серверная ошибка не должна молча портить транспорт); объявленному SSE - SSE и остаётся.
  • Проверки здоровья - pg-boss-cron объезжает поставленные + включённые подключения каждые 30 минут, пингует с экспоненциальным повтором, и ведёт лестницу статуса (здоров → stale после первых провалов → down с третьего) с деталями провала по каждому подключению.
  • Мьютекс подключения + карта статусов - connect/disconnect сериализуются по подключению; живые статусы приходят из раннера, не из базы, потому «тест» отражает правду мгновения.

Класс аудита

Всякая мутация маркетплейса и подключения пишет в реестр событий (mcp.installed / mcp.uninstalled / CRUD-руки) - неизменяемый реестр активности платформы несёт поверхность (по F-AUDIT-1), в тон операторской остальной платформы.

Читать дальше

Путеводитель несёт полную справку - поля каталога, install/uninstall, семантику пиннинга, транспорты expose-стороны - на /ru/docs/mcp-marketplace:

  • MCP Marketplace - путеводитель
  • Пост постарше о первом срезе маркетплейса: /ru/blog/mcp-marketplace
  • Факты этого поста: строки FACT-CENSUS.md F-MCP-1 (двунаправленный MCP + маркетплейс) и F-AUDIT-1 (реестр событий)

Provenance: Simmetric Chat docs/MCP_MARKETPLACE.md + packages/server/src/agent/mcpServer.ts/mcpClient.ts (транспорты + запас), services/mcpHealthCheckJob.ts, CHANGELOG.md v0.28.1 - на зафиксированном census'ом документальном состоянии (SHA aca5b8ff).

Похожие статьи