AWS Agent Registry Enables Runtime Tool Discovery for AI Agents
Disclosure: this post contains affiliate links. If you buy through them we may earn a commission at no extra cost to you. Learn more.
TL;DR: AWS Agent Registry is a new managed service that allows AI agents to discover Model Context Protocol (MCP) servers and agent-to-agent (A2A) capabilities at runtime through semantic search. The service addresses the scalability problem of hardcoded tool wiring as agent catalogs grow from a handful to hundreds of enterprise APIs. Agents use a Discover-Instantiate-Execute loop to find and use only relevant tools per request.
What's New
AWS has released AWS Agent Registry, a managed service designed to solve a critical scalability problem in enterprise AI agent deployments. While hardcoded tools work adequately for small-scale demos with a handful of capabilities, they become unmanageable as organizations scale to hundreds of internal APIs for pricing, support, orders, inventory, and customer data.
The service enables a runtime discovery pattern through a three-step "Discover, Instantiate, Execute" loop. Instead of compiling every tool into an agent at build time, orchestrators can now search approved, discoverable records at runtime and construct clients dynamically.
AWS Agent Registry catalogs both Model Context Protocol (MCP) servers and agent-to-agent (A2A) agents. Publishers register protocol-specific descriptors and searchable descriptions. The orchestrator sends natural-language queries to the Registry data plane, which returns record identity, name, description, record type, status, version, and protocol descriptors—but not invocation credentials, which must be obtained separately through trusted configuration paths.
The service integrates with Amazon Bedrock AgentCore Gateway, which exposes tools as MCP servers, and Amazon Bedrock AgentCore runtime, which hosts orchestrator and A2A agents. The architecture uses Amazon Cognito for JWT authorization on Gateway calls and IAM-authorized Boto3 calls for runtime invocations.
According to the announcement, the traditional hardcoded approach creates bottlenecks where "the model can spend more tokens disambiguating tool names than reasoning about the user's request." Each new capability requires code changes, redeployment, and coordinated releases across teams. AWS Agent Registry enables teams to ship capabilities on their own cadence.
The Registry supports manual approval workflows, ensuring only approved records are discoverable. Records contain searchable descriptions plus protocol-specific descriptors—MCP servers store server metadata and tool definitions, while A2A records contain agent cards with runtime endpoint URLs.
AWS released a Python reference sample demonstrating the complete implementation, including an order-management MCP server, two A2A agents (Pricing and Customer Support), and an orchestrator with no built-in tool knowledge. The sample includes three demo scenarios: an MCP-only call for order status, an MCP + A2A chain for pricing and discounts, and a pure semantic match test for return and refund requests.
Pricing and Availability
Pricing details for AWS Agent Registry were not disclosed in the announcement. The service is available now and integrates with existing Amazon Bedrock services including AgentCore Gateway and AgentCore runtime.
How to Try It
Developers can access a runtime-discovery Python sample that deploys all necessary dependencies. The sample includes deployment scripts, an orchestrator implementation in orchestrator_agent.py, utility modules for parsing Registry descriptors and creating clients in utils.py, and cleanup scripts.
The implementation requires AWS credentials and uses the Agent Registry control-plane client for Registry and record lifecycle operations, plus the data-plane client for runtime discovery. The sample configures registries with manual approval and IAM authorization, and currently uses Anthropic Claude Sonnet models through cross-Region model IDs.
Who It's For
AWS Agent Registry targets enterprise organizations dealing with large-scale agent deployments, particularly those exposing hundreds of internal APIs to agentic consumers. The service addresses scenarios common in enterprise SaaS engagements where teams manage extensive API surfaces and need to avoid build-time wiring bottlenecks.
Development teams seeking to decouple agent capabilities from orchestrator code and ship on independent release cadences will benefit most from the runtime discovery pattern.
Alternatives
Organizations can continue using traditional hardcoded tool wiring for small-scale deployments with limited tool catalogs. Make offers workflow automation that could complement agent orchestration needs. Other cloud providers offer their own agent orchestration services, though specific runtime discovery capabilities may vary.
Tools mentioned
FAQ
What problem does AWS Agent Registry solve?
AWS Agent Registry addresses the scalability problem of hardcoded tool wiring in AI agents. As agent tool catalogs grow from a handful to hundreds of enterprise APIs, hardcoded approaches become unmanageable, requiring code changes and redeployments for each new capability. The Registry enables runtime discovery through semantic search instead.
Does AWS Agent Registry provide authentication credentials?
No. Registry search results return connection metadata including record identity, name, description, and protocol descriptors, but do not include invocation credentials or authentication schemes. Applications must obtain and apply appropriate credentials through separate, trusted configuration paths.
What protocols does AWS Agent Registry support?
AWS Agent Registry supports Model Context Protocol (MCP) servers and agent-to-agent (A2A) agents. MCP descriptors contain server metadata and tool definitions, while A2A descriptors contain agent cards with runtime endpoint URLs.
How does the Discover-Instantiate-Execute loop work?
The orchestrator first discovers tools by sending natural-language queries to AWS Agent Registry, which returns matching records. It then instantiates clients from the returned descriptors, applying separately-obtained credentials. Finally, it executes by building an ephemeral inner agent with only the discovered tools, which are torn down after the request completes.