AWS научил реестр MCP-серверов обновляться сам: схема тулов без ручных правок

Любой внутренний каталог умирает одинаково. Сначала он точный, потом кто-то добавляет в сервис новую функцию и забывает поправить запись, а через месяц все ходят в код и в чат, потому что каталогу больше никто не верит. С реестром MCP-серверов та же история, только последствия неприятнее: агент может вызвать инструмент по старой схеме и получить непонятное поведение без явной ошибки.

AWS опубликовала разбор того, как не допустить этого в Agent Registry, части Amazon Bedrock AgentCore. Идея простая: обновление записи не должно зависеть от дисциплины разработчика. Его должно запускать само событие деплоя.

Как это устроено

Цепочка из пяти сервисов выглядит так.

• Разработчик обновляет MCP-сервер, например командой agentcore deploy. Это вызывает API UpdateAgentRuntime, и CloudTrail записывает вызов как management event.
• EventBridge по правилу (источник aws.bedrock-agentcore, имя события UpdateAgentRuntime) пересылает событие на центральную шину. В мультиаккаунтной схеме она находится в аккаунте реестра.
• Lambda достаёт из события ARN рантайма и собирает из него URL вызова MCP-сервера. Регион и ID аккаунта она берёт из того же ARN.
• Lambda получает OAuth-токен через AgentCore Identity: сначала workload-токен для себя, затем M2M-токен от credential provider нужного аккаунта. Клиентских секретов в переменных окружения нет.
• Lambda вызывает initialize, затем tools/list и получает актуальный список инструментов.
• Затем она ищет запись реестра, в схеме которой встречается тот же ARN (или закодированный ARN, или URL), и сравнивает списки.

Где здесь аккуратная инженерия

Сравнение сделано без лишних записей. Инструменты сортируются по имени и сводятся к трём полям: name, description и inputSchema. Запись в реестр уходит, только если эти поля различаются, а в логах остаётся, что именно добавили или убрали.

Ещё две полезные детали. Для каждого аккаунта настраивается свой credential provider (переменная вида CREDENTIAL_PROVIDER_{ACCT_ID}), поэтому одна Lambda обслуживает серверы из разных аккаунтов. А перед запросом код проверяет, что URL начинается с https://, и это закрывает неприятные сценарии вроде file://.

Представьте команду платежей, которая добавила в свой MCP-сервер инструмент refund_status. Раньше команда поддержки узнала бы об этом из чата через неделю. Теперь через 5–15 минут после деплоя запись в реестре уже содержит новый инструмент с актуальной схемой, а в логах Lambda видно, что изменилось.

Ограничения, о которых стоит знать

Первое: сервис не создаёт записи. Lambda в примере обновляет только уже зарегистрированные записи, которые заведены при онбординге и содержат ARN рантайма в mcpServer.data. Записи в статусе DRAFT пропускаются, нужен APPROVED. Это сохраняет существующий процесс согласования, но первичную регистрацию придётся автоматизировать отдельно.

Второе: задержка. CloudTrail доставляет события примерно за 5–15 минут, так что для сценария «задеплоил и сразу вызываю» это не подходит. Для каталога, который читают люди и агенты при поиске инструментов, такой лаг обычно терпим.

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

Есть и два наблюдения по самому коду из статьи. Поиск записи перебирает список реестра и для каждого элемента делает отдельный get-запрос, а в показанном фрагменте нет пагинации. На десятках серверов это нормально, на сотнях стоит добавить индекс или хранить сопоставление ARN и ID записи отдельно. Часть кода в исходной статье обрывается, так что полный вариант лучше смотреть в репозитории примера.

Что делать на практике

Если вы строите внутренний каталог MCP-серверов, берите паттерн целиком: событие деплоя, затем опрос tools/list, затем diff, затем запись. Он не привязан к AWS: на любом облаке можно собрать то же самое из аудит-лога, шины событий и функции. Главное правило такое: источник истины о схеме инструментов — сам работающий сервер, а запись в каталоге лишь его отражение, которое нельзя оставлять на ручное обновление.