AWS Agent Registry lets AI agents find their tools at runtime

The problem with hardcoded tools

According to AWS, hardcoded tools work fine for a handful, start to degrade at a few dozen, and become unmanageable beyond that. Enterprise systems can expose hundreds of internal APIs for pricing, support, orders, inventory and customer data. In such systems, AWS says, the model can spend more tokens disambiguating tool names than reasoning about the user's request.

Each new capability also requires a code change in the orchestrator, a redeploy, and a coordinated release across teams that would rather ship on their own cadence. AWS describes this as a pattern seen in enterprise SaaS engagements where large internal API surfaces are exposed to agentic consumers.

The proposed alternative is to let the agent discover relevant tools at runtime. AWS Agent Registry is a managed service for cataloging and discovering Model Context Protocol (MCP) servers, agents and agent skills. Publishers register protocol-specific descriptors and searchable descriptions, and an orchestrator can search approved, discoverable records and use the returned endpoint and descriptor content to construct a client.

Discover, instantiate, execute

In the sample, the orchestrator agent has no built-in knowledge of tools or agents. The loop works in three steps.

• Discover: the orchestrator sends a natural-language query to the Registry data plane. Results include record identity, name, description, record type, status, version and protocol descriptors such as MCP server metadata or an A2A agent card. They do not include invocation credentials.
• Instantiate: for each returned record, the orchestrator builds a client from the descriptor type. The MCP descriptor points to an Amazon Bedrock AgentCore Gateway endpoint, and the orchestrator fetches a Cognito OAuth access token separately. A2A records contain an agent card whose URL identifies an AgentCore runtime endpoint, which is invoked through the boto3 data-plane client using the caller's AWS credentials.
• Execute: an ephemeral inner agent is built with only the discovered tools, the large language model picks the right ones, and the result is synthesized for the user. Afterwards the inner agent and its clients are torn down, and the next request gets a fresh search and tool set.

AWS stresses that Registry discovery supplies connection metadata, not authentication material. The application must obtain credentials through a separate, trusted configuration path.

Reference architecture and approval workflow

The sample deploys an order-management MCP server through AgentCore Gateway, two A2A agents (Pricing and Customer Support) on AgentCore runtime, a Registry and an orchestrator. The architecture also uses Amazon Bedrock, Amazon Cognito, AWS Lambda and AWS Secrets Manager. The sample currently configures an Anthropic Claude Sonnet model through a cross-Region model ID.

Governance is built into the catalog. With auto-approval turned off, a new record must move from DRAFT to PENDING_APPROVAL and then APPROVED. The submit and status-update actions are IAM-authorized, so publisher and approver permissions can be separated. Only approved records are returned by the discoverable data plane.

Records use a recordType field: MCP servers use "MCP" and A2A-backed agents use "AGENT". Protocol metadata sits under mcpServer or a2aAgentCard in the descriptors object. AWS advises writing descriptions in user-facing language that distinguishes a capability from neighboring records, and evaluating search quality with representative queries. The post says it does not assume that catalog growth automatically improves ranking.

Demo scenarios and what it means

Three demos exercise the loop. The first is an MCP-only call for order status. The second chains MCP and A2A for pricing and discounts. The third tests a pure semantic match against ambiguous intent, return and refund, where those words do not appear in the matched A2A agent's name.

For teams with large internal API catalogs, the approach aims to remove the need to change and redeploy the orchestrator for every new capability. According to AWS, new integrations become usable after registration and approval. The sample code, including the deployment script, orchestrator, helper modules and cleanup script, is linked from the AWS post.