Discover tools at runtime with AWS Agent Registry
Amazon Web Services Vibhu Pareek
AWS says agents can find tools at runtime instead of being hardcoded. That could save teams from constant redeploys as tool catalogs grow.
Based on reporting by Amazon Web Services, Vibhu Pareek — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
AWS is pushing a simpler answer to a messy enterprise problem: stop hardcoding every tool into an agent and let it discover what it needs at runtime. The company says that works fine when there are only a few tools, but starts to break down as internal APIs pile up across pricing, support, orders, inventory, and customer data. Then the model wastes effort sorting out tool names instead of helping the user.
The new piece here is AWS Agent Registry, a managed catalog for Model Context Protocol servers, agents, and agent skills. Publishers register protocol-specific descriptors and searchable descriptions. At runtime, an orchestrator can search the registry, get back the record details and endpoint metadata, and build a client on the fly. What it does not get are the credentials or auth scheme.
AWS’s sample implementation follows a Discover → Instantiate → Execute flow. The orchestrator starts with no built-in knowledge of tools or agents, queries the registry, parses whatever comes back, and creates either an MCP client or an A2A client depending on the record type. Then it spins up an inner agent for that request only, lets the model choose the right capability, returns the answer, and tears everything down afterward.
The demo architecture is built around Amazon Bedrock AgentCore Gateway, Amazon Bedrock AgentCore runtime, Amazon Bedrock, Amazon Cognito, AWS Lambda, and AWS Secrets Manager. In the sample, order-management tools are exposed through Gateway as MCP, while Pricing and Customer Support run as A2A agents on AgentCore runtime. AWS also says only records that clear the approval workflow show up in the discoverable data plane.
The examples are pretty pointed. One request uses only MCP for order status, another chains MCP and A2A for pricing and discounts, and a third uses semantic matching for a return-and-refund request even though those words are not in the matched agent’s name. That last one is the real pitch: the system is supposed to find the right capability from meaning, not from whatever someone remembered to wire in six months ago.
My take — AI-written commentary, not fact-checked reporting
This is the boring kind of infrastructure change that usually matters more than the flashy demo. Hardcoded agent wiring is fine until the tool shelf looks like a small airport, then everyone pretends the redeploys are part of the product. Centralized discovery with separate approval and auth is the right instinct, because at least the machine can stop playing telephone with your API catalog.
Read more about this at: Amazon Web Services