Discover tools at runtime with AWS Agent Registry

Amazon Web Services launched AWS Agent Registry, a managed service designed to catalog and discover Model Context Protocol servers, agents, and agent skills through runtime semantic search. As outlined in AWS Machine Learning Blog's report, the platform addresses scaling limits where hardcoding dozens or hundreds of internal API tools directly into an orchestrator degrades reasoning performance and exhausts token budgets. Enterprise architectures connecting large SaaS environments can shift from compiling tool definitions at build time to fetching approved integration endpoints on demand.

This report examines the Discover, Instantiate, and Execute pattern demonstrated by AWS, detailing how orchestrators parse protocol descriptors without baking in static credentials. The implementation covers development teams managing multi-agent systems, organizations deploying Model Context Protocol gateways, and architects building on Amazon Bedrock AgentCore.

Discover tools at runtime with AWS Agent: what actually changed

Traditional agent architectures compile every reachable tool directly into the orchestrator codebase. When enterprise systems expose hundreds of internal endpoints across customer support, pricing, orders, and inventory, model prompts fill with verbose tool definitions. Foundation models end up burning tokens disambiguating competing function signatures rather than executing instructions, and shipping an update to any single capability forces an orchestrator code change and redeployment.

AWS Agent Registry replaces that build-time wiring with dynamic runtime retrieval over a governed data plane. Instead of carrying persistent references to tools, an orchestrator queries the registry with natural-language user intent to fetch only relevant capabilities. Records remain invisible to the discovery layer until passing configured approval workflows, allowing publisher teams and centralized orchestrator teams to release capabilities independently.

Discover tools at runtime with AWS Agent: how it works

The operational cycle runs across three phases named Discover, Instantiate, and Execute. During discovery, the orchestrator issues a natural-language search query to the Agent Registry data plane, which returns approved records containing names, descriptions, record types, versions, and protocol descriptors. For Model Context Protocol servers, the descriptor packages server metadata under dataSchemaVersion 2025-12-11 alongside tool definitions under dataSchemaVersion 2025-06-18, while agent-to-agent entries supply an agent card using dataSchemaVersion 0.3.

During instantiation, the orchestrator reads these descriptors to construct client wrappers on the fly. In the reference Python sample, Model Context Protocol records point to an Amazon Bedrock AgentCore Gateway endpoint backed by AWS Lambda, authorized through an independently fetched Amazon Cognito JSON Web Token. Agent-to-agent records point to an Amazon Bedrock AgentCore runtime hosting pricing and support agents, invoked via IAM-signed Boto3 calls. The orchestrator spawns an ephemeral inner agent using an Anthropic Claude Sonnet model hosted on Amazon Bedrock, executes the turn, returns the result, and immediately destroys the inner client instances.

Discover tools at runtime with AWS Agent: why it matters now

Scaling agent tool sets beyond a handful of integrations introduces severe latency and cost bottlenecks. When orchestrators must swallow hundreds of function definitions within system prompts, context windows shrink rapidly and attention mechanisms struggle with overlapping schemas. Shifting discovery to an external registry restores clean context windows by ensuring that the reasoning model only evaluates tools relevant to the active prompt.

Governance and operational isolation drive equal value. The control-plane client separates publishing permissions from approver roles through AWS Identity and Access Management policies, routing entries through DRAFT, PENDING_APPROVAL, and APPROVED statuses. Because records supply connection descriptors rather than invocation secrets, security boundaries remain intact while eliminating coordinated deployments across disparate service teams.

Discover tools at runtime with AWS Agent: who is affected

Software engineers and platform architects deploying multi-agent systems on AWS are directly impacted by this pattern. Teams maintaining enterprise SaaS platforms with sprawling internal APIs can publish endpoints as standalone Model Context Protocol servers or Bedrock AgentCore runtime agents, decoupling service updates from downstream client implementations.

Orchestrator maintainers also gain operational independence. Instead of coordinating release schedules to add support for new corporate systems, engineers can build generic orchestrators that adapt dynamically to any approved tool appearing in the registry. Infrastructure teams maintain granular control through IAM roles, AWS Secrets Manager, and Amazon Cognito token issuers.

Discover tools at runtime with AWS Agent: what to watch

Registry search precision will dictate real-world success as catalogs grow. Because discovery relies on natural-language matching across descriptions, teams must draft clear, user-facing summaries that distinguish adjacent tools. In tests involving ambiguous requests such as return and refund inquiries where exact terms were absent from agent titles, semantic search matched appropriate support agents, but larger catalogs require continuous ranking evaluation.

Authentication plumbing requires deliberate architectural design outside the registry itself. Because registry search results deliberately exclude invocation credentials and authentication schemes, client applications must establish parallel paths using Cognito OAuth tokens or IAM signing to talk to AgentCore Gateway and AgentCore runtime endpoints.