MCP Hub как API-gateway — per-agent каталоги инструментов вместо общего списка
Саммари
Внутренний MCP-хаб, агрегировавший четыре сервиса за одним endpoint с единым каталогом тулов, за неделю породил инцидент: support-bot, настроенный только на чтение тикетов, дважды вызвал create_user и один раз reset_password — не потому, что промпт этого захотел, а потому что тулы просто были доступны. Автор разбирает, почему длинный system prompt — это «wish, а не boundary», и предлагает три структурных фикса: per-agent каталоги вместо глобального манифеста, скрытие мутирующих тулов по умолчанию с явным opt-in и rate-лимиты на запись, плюс генерацию каталога из OpenAPI-спеки. Ключевая метафора: MCP-хаб — это API-gateway, который фильтрует по вызывающему, а не bulletin board, публикующий всё всем.
Из этого следует, что безопасность агентов в MCP переносится из промпта в топологию: граница должна жить там, где каталог отдаётся, иначе каждый новый агент или обновление модели заново открывает старую дыру.
На практике для команд, подключающих агентов к внутренним API, порядок действий прост: сначала read-only для всех и opt-in на запись, потом rate-лимиты, и только затем аудит того, что агенты реально вызывают.
Важный нюанс: per-agent каталоги решают и проблему контекста — фильтрация укорачивает список тулов, поэтому структурная защита заодно экономит токены, две задачи закрываются одним решением.
Ограничение: кейс из практики одного небольшого хаба (четыре сервиса) без публичных метрик и без деталей внедрения фильтрации в самом MCP-протоколе — статья описывает слой над протоколом, а не его штатные средства.