AWS Agent Registry lets agents discover enterprise tools at runtime

AWS is pitching runtime discovery as a way to manage a problem that can emerge when enterprise agents need access to dozens or hundreds of internal services. Hardcoded integrations may work for a small tool set, but AWS says they can become cumbersome as catalogs grow: every new capability can require changes to orchestration code and another deployment.

The company’s AWS Agent Registry is a managed catalog for Model Context Protocol (MCP) servers, agents and agent skills. In the reference sample, an orchestrator searches the catalog with a natural-language request, receives matching approved records and their protocol descriptors, and uses those details to build clients for the relevant capabilities. AWS describes the pattern as “Discover → Instantiate → Execute.”

That discovery flow does not hand an agent the credentials needed to call a service. AWS says the registry returns connection metadata and descriptors, while applications must obtain authentication material separately through a trusted configuration path. In the sample, MCP calls use a separately fetched Cognito OAuth token, while calls to agent endpoints are made with AWS credentials.

The demo deploys an order-management MCP server through Amazon Bedrock AgentCore Gateway, along with pricing and customer-support agents hosted on AgentCore Runtime. For each request, the orchestrator creates a temporary inner agent equipped with the tools found in the search, then tears down that agent and its clients once the turn is finished. The sample tests an order-status lookup, a pricing request that combines MCP and agent-to-agent capabilities, and a return-and-refund query matched to a customer-support agent.

Registry records in the example require approval before they become discoverable: publishers submit records for review, and only approved entries are returned through the runtime search interface. AWS also cautions that a larger catalog does not automatically improve search ranking; descriptions need to distinguish capabilities, and search quality should be tested against representative queries.

The post presents a reference implementation, not evidence that runtime discovery will improve agent performance across enterprise deployments. Its narrower point is architectural: teams can register and approve capabilities separately from the orchestrator’s code, while the orchestrator searches for relevant tools at request time rather than carrying every integration as a fixed, built-in dependency.