On October 20, 2026 the AWS Machine Learning blog published a walkthrough of AWS Agent Registry, a managed service for cataloging and discovering MCP servers, agents and agent skills, with a sample in which an orchestrator agent finds its tools at request time instead of having them wired in. The pitch: hardcoded tool lists "work fine for a handful, start to degrade at a few dozen, and become unmanageable beyond that." In enterprise systems with hundreds of internal APIs for pricing, support, orders and inventory, AWS says the model can spend more tokens disambiguating tool names than reasoning about the user's request.
This is a how-to walkthrough of AWS's post, with our commentary on governance and security. We have not deployed the sample. If you are new to the underlying standard, start with our guides to Claude connectors and MCP servers and building your first MCP server.
TL;DR
| Question | Short answer |
|---|---|
| What is it? | A managed, searchable, approval-gated catalog of MCP servers, agents and skills |
| Core loop | Discover, instantiate, execute |
| What does search return? | Identity, name, description, type, status, version, protocol descriptors |
| What does it not return? | Invocation credentials or the auth scheme |
| Search type | Hybrid keyword and semantic |
| Governance | DRAFT, PENDING_APPROVAL, APPROVED with IAM-authorized transitions |
| Sample stack | AgentCore Gateway, AgentCore runtime, Cognito, Lambda, Secrets Manager, Bedrock |
| Model in sample | An Anthropic Claude Sonnet model through a cross-Region ID |
| Evidence of benefit | A reference sample; no measured accuracy or cost figures |
The problem: build-time wiring
Hardcoded tool endpoints versus runtime discovery with AWS Agent Registry
Image: AWS
In the usual agent design, the orchestrator is compiled with its tools. Adding a capability means a code change, a redeploy and a coordinated release across teams that "would much rather ship on their own cadence," in AWS's words. With a few tools this is fine. With dozens or hundreds, two things break. The tool list in the prompt grows until the model confuses similar names, and release coordination becomes the bottleneck. Our look at AWS's trust-in-depth guidance for agent autonomy covers how the same company thinks about bounding what agents may do.
The solution: discover, instantiate, execute
The sample's orchestrator "has no built-in knowledge of tools or agents." For each request it does three things.
1. Discover
The orchestrator sends a natural-language query to the registry's data plane. The response lists matching records with identity, name, description, record type, status, version and descriptors such as MCP server metadata or an A2A agent card. Search is hybrid keyword and semantic, via a search_discoverable_registry_records call that takes registry IDs, a query and a result limit.
2. Instantiate
For each record the orchestrator builds a client from the descriptor type. An MCP descriptor points at an endpoint, in the sample the AgentCore Gateway that exposes order-management Lambda tools as an MCP server. The orchestrator fetches a Cognito OAuth token separately and uses it to create the MCP client. An A2A record contains an agent card whose URL names an AgentCore runtime endpoint, invoked through the boto3 data-plane client, which signs the request with the caller's AWS credentials. In AWS's words: "Registry discovery supplies connection metadata, not the authentication material."
3. Execute
Orchestrator per-request flow: outer agent searches the Registry and builds a request-scoped inner agent
Image: AWS
An ephemeral inner agent is built with only the discovered tools; the 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. This request-scoped design keeps the prompt small and avoids stale tool lists.
The registration model and approval workflow
Publishers create records with a searchable description and a protocol-specific descriptor. The sample uses recordType of MCP for servers and AGENT for A2A-backed agents, with metadata stored under mcpServer or a2aAgentCard. The descriptors carry connection metadata but not credentials.
Governance is where the design is most interesting for enterprises. With auto-approval off, a new record starts as DRAFT, moves to PENDING_APPROVAL, and only becomes APPROVED after a second action. The submit and status-update actions are IAM-authorized, "allowing publisher and approver permissions to be separated." Only approved records are returned by the discoverable data plane. That gives a security team a gate: a team can publish a new tool, but agents cannot find it until someone with approver rights signs off.
AWS gives advice on writing descriptions: use user-facing language that distinguishes a capability from its neighbors, because search quality depends on it. This is the same lesson as writing good MCP tool descriptions or skill descriptions. See our explainer on MCP server directories for the public-registry analogue.
What a good record description looks like
Because search is semantic, the description is the retrieval key. Here is our own illustration of the difference, not an example from AWS:
| Weak description | Stronger description |
|---|---|
| "Order API" | "Look up the status, shipping events and delivery estimate of a customer order by order number" |
| "Support agent" | "Handles returns, refunds and exchanges: checks eligibility against policy and opens a return case" |
| "Pricing tool" | "Calculates a quote and allowed discount for a customer segment and quantity; cannot approve exceptions" |
The stronger versions state the user-facing intent, the inputs and, where useful, what the capability cannot do. That last part helps the model avoid choosing a tool that will fail. Test by writing ten phrasings of the same request, including ones that avoid the tool's name, and checking that the right record ranks first.
What this means for teams running many agents
Runtime discovery shifts work from developers to platform owners. Instead of each agent team maintaining a tool list, a central team curates the catalog, approvers decide what is discoverable, and agent teams focus on prompts and evaluation. That mirrors how companies already treat internal APIs through developer portals. The trade is a new dependency: if the registry is slow or down, agents lose their tools, so design a cached fallback for the most important capabilities and set timeouts on search.
Versioning matters too. Records carry a version, and the status field lets you retire a capability without touching the orchestrator. Decide in advance how you will handle breaking changes: publish a new record version, run both for a period, and deprecate the old one only after logs show no calls.
The demos and their limits
The sample runs three scenarios: an MCP-only call (order status), a chained MCP plus A2A call (pricing and discounts), and a semantic match for ambiguous intent, where a return-and-refund query finds the Customer Support agent even though those words are not in its name. AWS is careful: "Treat this as a demo result, not a general claim that ranking improves merely because the catalog is larger," and says the post "does not assume that catalog growth automatically improves ranking." Evaluate with representative queries from your own users.
No accuracy, latency or cost numbers are published. The case for runtime discovery is architectural, not measured.
Security notes we would add
- Registry as attack surface. A catalog that agents trust is a target. A malicious or compromised record could steer an agent to a hostile endpoint. The approval gate helps; pair it with endpoint allow-lists and review of descriptor changes.
- Tool poisoning and prompt injection. Descriptions are read by a model. A description that contains instructions is a classic injection route. Review descriptions as you would code. Our post on the AgentCore hijack research shows why agent platforms deserve scrutiny.
- Credentials stay out of discovery. This is a good design choice: discovery metadata can be logged and cached without leaking secrets. Make sure your separate credential path is least-privilege and per-tool.
- Dynamic scope. Because tools change per request, policy has to be evaluated at call time, not only at deploy time. Money-moving tools, like those in AgentCore Payments, need their own limits.
- Observe everything. Log which records were discovered and which were invoked for each request.
For an independent layer that checks agent actions before they run, see AgentBeam, the agent security platform from the explainx.ai team.
When to use it, and when not to
Use runtime discovery if you have many tools owned by many teams, if tools change faster than your orchestrator releases, or if you need a governed catalog with separate publisher and approver roles. Skip it if you have a dozen stable tools in one codebase: a static list is simpler, faster and easier to audit. The registry also ties you to AWS's stack in this sample (AgentCore, Cognito, IAM), though the descriptor formats are the MCP and A2A standards, which keeps the tools themselves portable.
Try it
AWS links a sample directory with a deployment script, orchestrator, helper modules and a cleanup script. The flow is: deploy the dependencies, create and populate the registry, verify discovery, deploy the orchestrator and run the three demos. Run the cleanup script afterward to avoid charges. Start with a registry that has manual approval and a few records, and test search with ten real user questions before adding more.
Details reflect AWS's October 20, 2026 blog post; the service and sample may change.