Runtime tool discovery with AWS Agent Registry replaces the previous model of embedding fixed tool endpoints in an orchestrator. Engineers responsible for AI, cloud platforms, DevOps, or security benefit from a catalog‑driven approach that scales without frequent code changes or redeployments.
What Changed: From Hard‑Coded Tools to Registry‑Driven Discovery
Earlier implementations required each new capability—whether an MCP server or an A2A agent—to be added to the orchestrator’s source, compiled, and redeployed. As the number of internal APIs grows into the dozens or hundreds, the token budget for disambiguating tool names becomes a bottleneck, and coordination across teams slows release cycles. AWS Agent Registry introduces a managed service where publishers register protocol descriptors and searchable metadata, allowing the orchestrator to query for approved capabilities at runtime.
Discover‑Instantiate‑Execute Loop
Discover
The orchestrator issues a natural‑language query to the Agent Registry data plane. The response includes record identifiers, names, descriptions, types, status, version, and protocol‑specific descriptors (for example, MCP server metadata or A2A agent cards). Authentication credentials are deliberately omitted; the orchestrator must obtain them through a separate trusted path.
Instantiate
For each record, the orchestrator builds a client based on the descriptor. MCP server records point to a Bedrock AgentCore Gateway endpoint; the orchestrator retrieves a Cognito OAuth token separately and creates an MCPClient with that token. A2A agent records contain a runtime endpoint URL; the orchestrator invokes it via the boto3 Agent Registry client, which signs the request with the caller’s AWS credentials. In both cases, the registry supplies connection metadata, not the authentication material.
Execute
An ephemeral inner agent is instantiated with only the discovered tools. The LLM selects the appropriate tool(s) for the user request, executes them, and returns the synthesized result. After the turn completes, the inner agent and its clients are torn down, ensuring a fresh discovery on the next request.
Architectural and Operational Implications
- Decoupled release cadence: Teams can register new MCP servers or A2A agents without modifying the orchestrator code, allowing independent deployment schedules.
- Catalog governance: The registry acts as a single source of truth for approved capabilities, simplifying inventory and audit processes.
- Reduced redeployment overhead: Adding or retiring a tool no longer triggers a full orchestrator rebuild, lowering CI/CD load.
- Dynamic client construction: Runtime code must handle descriptor parsing and client instantiation for multiple protocol types.
Security Implications
- Separate credential paths: Since the registry does not return invocation credentials, practitioners must manage token acquisition (e.g., Cognito OAuth) and AWS credential signing independently, preserving principle of least privilege.
- Approval workflow: Only records marked as approved and discoverable are returned, implying a governance step before exposure to the orchestrator.
- Transient agents: Ephemeral inner agents limit the window of exposure for any compromised tool client.
- Auditability: Registry search logs provide visibility into which capabilities were queried and instantiated.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopt the discover‑instantiate‑execute pattern by integrating AWS Agent Registry queries into your orchestrator logic. Ensure you have a reliable process for fetching the required OAuth tokens or AWS credentials separate from the registry response. Update monitoring to capture registry search activity and client creation events. Finally, establish a governance workflow that reviews and approves new tool registrations before they become discoverable, keeping the runtime catalog both useful and secure.
