agents-connect

Навык agents-connect из AWS Agent Toolkit for AWS предназначен для подключения агента Amazon Bedrock AgentCore к внешним API, MCP-серверам, Lambda-функциям и другим инструментам через AgentCore Gateway. Он также описывает ограничение доступа с помощью Cedar policies. Это operational guide для выбора схемы подключения и последовательной настройки, а не доказательство того, что конкретный AWS-ресурс уже создан, credentials действуют или production-развёртывание завершилось успешно. Работа начинается с проверки версии agentcore: источник требует CLI 0.9.0 или новее. Затем навык предлагает прочитать agentcore/agentcore.json, определить framework и уже настроенные шлюзы в agentCoreGateways, после чего уточнить, что именно требуется подключить. Для MCP-сервера, Lambda, OpenAPI-схемы и API Gateway используются разные типы gateway target. Для сервиса без MCP, OpenAPI, Lambda или другой практичной оболочки есть резервный путь с credential и прямым вызовом из кода, но он не должен быть первым выбором только потому, что написать HTTP-клиент кажется быстрее. Основная рекомендация — предпочитать Gateway target. В этой схеме credential providers добавляют OAuth, API key или IAM-аутентификацию на исходящем пути, поэтому код агента не обязан видеть секрет. Каталог Gateway делает инструменты обнаруживаемыми для MCP-клиента и позволяет framework привязать их без ручного списка в entrypoint. Cedar может разрешать или запрещать вызовы по субъекту, имени инструмента и значениям аргументов. Если шлюз разрастается примерно за двадцать инструментов, источник предлагает включить встроенный semantic search через x_amz_bedrock_agentcore_search, чтобы на каждый ход передавался релевантный набор, а не весь каталог. Навык помогает выбрать target: MCP-сервер обычно оформляется как mcp-server, управляемая Lambda — как lambda-function-arn, HTTP API с OpenAPI — как open-api-schema, уже существующий API Gateway — как api-gateway, а AWS-сервис с Smithy-моделью — как smithy-model. Матрица аутентификации важна: CLI-параметр oauth описывает machine-to-machine OAuth, а пользовательский authorization-code flow требует API/SDK настройки с AUTHORIZATION_CODE и defaultReturnUrl. Для MCP IAM через SigV4 настраивается через API для поддерживаемых AWS endpoints, а API key для MCP target на уровне API не поддерживается; в таком случае источник направляет к прямому вызову из кода и credential-пути. Direct API call допустим, если нужен потоковый или двунаправленный протокол, который Gateway пока не фронтит, измеренный latency-critical hot path, vendor binary SDK без HTTP-поверхности, AWS SDK с уже имеющейся IAM-ролью runtime либо конкретный blocker, делающий Gateway регрессией. В остальных случаях прямой вызов усложняет хранение секретов, каталогизацию и policy enforcement. После настройки нужно отдельно выполнить deploy, получить фактический gateway URL, сгенерировать клиентский код, проверить credentials и обработать local-dev gap: локальный режим не предоставляет все deploy-зависимые gateway URLs и память. Любые выводы о готовности должны опираться на реальные команды и ответы AWS, которых сам skill не подменяет.