# Automating AWS Agent Registry updates with push-based architecture > Source: > Published: 2026-11-11 20:52:48+00:00 ## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/) # Automating AWS Agent Registry updates with push-based architecture Every time a Model Context Protocol (MCP) server published in the AWS Agent Registry, a capability of Amazon Bedrock AgentCore, gains a new tool or updates its schema, the registry record must be updated too. Without automated push-based sync, consumers discover stale metadata. For organizations managing multiple MCP servers across accounts, such a sync keeps catalog records current within an existing governance workflow. In most enterprise deployments, a catalog’s value depends on its freshness. If a developer deploys a new tool on Monday, but the registry record still reflects last week’s schema, consumers lose trust in the catalog. Stale metadata directly reduces registry reliability, leading teams to inadvertently build dependencies on inaccurate information. When an engineer adds a tool to an MCP server but forgets to update the catalog: - Consumers miss out on the new capability entirely. - Applications might call the tool using an outdated schema, causing unexpected runtime behavior or silent workflow deviations. Multiplied across teams, this lack of automation erodes trust in the registry. Organizations ultimately fall back on ad hoc discovery mechanisms like hardcoded endpoints, informal knowledge sharing, and stale documentation. In this post, we outline an event-driven architecture that automates these updates using AWS CloudTrail, Amazon EventBridge, and AWS Lambda. ## Architecture overview The following solution brings these services together into an event-driven pipeline that detects runtime changes and synchronizes them to the registry automatically. The architecture supports both multi-account and single-account environments: - Single-account setup: For straightforward deployments, all components reside within Account A. Cross-account forwarding setup isn’t needed as events flow directly within Account A. - Multi-account setup: This involves two accounts where runtime events from Account B are securely forwarded to Account A. - **Account A (registry account)** owns the AWS Agent Registry, the Amazon EventBridge rule, the push-sync Lambda function, and CloudTrail logs. - **Account B (MCP server account)** hosts the MCP server runtime and the Amazon Cognito OAuth provider used for authentication. The sample uses two accounts, but you can scale the architecture for multiple accounts, with Account A as the registry account and multiple AWS accounts similar to Account B for different MCP servers. The following diagram shows the end-to-end event flow for an update to an MCP server in Account B. The captured event is forwarded to Account A, where a Lambda function queries the MCP server for its tools and updates the matching registry record. The architecture uses five AWS services: - **AWS CloudTrail** captures`UpdateAgentRuntime` API calls as management events. - **Amazon EventBridge** routes matching events to the Lambda function, with cross-account forwarding supported. - **AWS Lambda** queries the MCP server for its current tools, diffs against the registry, and updates the record if changed. - **AWS Agent Registry** stores MCP server records and their tool schemas as the central source of truth. - **AgentCore Identity, a capability of Amazon Bedrock AgentCore,** brokers OAuth token exchanges securely, so the Lambda authenticates without storing secrets. ## How it works: business logic flow After it’s deployed, the pipeline runs the following end-to-end workflow: 1. **Trigger** : A developer in**Account B** updates an MCP server, which calls the`UpdateAgentRuntime` API in Amazon Bedrock AgentCore, and AWS CloudTrail captures the event. 2. **Route** : Amazon EventBridge catches the CloudTrail event and forwards it to the central event bus in**Account A** . 3. **Parse** : The sync Lambda in**Account A** extracts the runtime Amazon Resource Name (ARN) from the event payload and dynamically constructs the MCP server’s invocation URL. This is how it knows which server in**Account B** to query. 4. **Authenticate** : The Lambda generates a secure OAuth bearer token through AgentCore Identity. 5. **Fetch** : The Lambda calls the MCP server (`initialize` , then`tools/list` ) to retrieve the latest tools information. 6. **Sync** : The Lambda finds the matching registry record by its ARN, evaluates the differences, and updates the registry if the schema has changed. This flow assumes that the Agent Registry in Account A already contains a pre-registered record for the MCP server (created during initial onboarding). The Lambda function in this sample updates existing records only. It doesn’t generate new ones. This same flow works in a single-account setup where all resources (registry, Lambda, Amazon EventBridge rule, and MCP server) reside in one account. In that case, skip the cross-account forwarding step. Events flow directly within the same account’s Amazon EventBridge bus. ## Technical walkthrough This section walks through the workflow for a single MCP server update with two accounts as depicted in the architecture diagram. The same flow executes independently for each server that emits an `UpdateAgentRuntime` event. The Lambda handles one event at a time, scaling naturally with the Amazon EventBridge invocation model. ### Step 1: Event capture and routing for cross-account setup When a developer deploys or updates an MCP server, the `UpdateAgentRuntime` API is called, either by the AgentCore CLI (`agentcore deploy`) or directly. AWS CloudTrail records this as a management event in Account B, with a delivery delay of approximately 5–15 minutes. The event is then delivered to Account A’s default Amazon EventBridge bus. For a cross-account setup, Account B’s Amazon EventBridge forwards matching events to Account A’s event bus through a cross-account rule. The Amazon EventBridge rule target in Account A invokes the sync Lambda, passing the full CloudTrail event JSON as the input payload. The Amazon EventBridge rule pattern: ### Step 2: Extract the MCP server URL The Lambda parses the runtime ARN from the event. It extracts the hosting Account ID and AWS Region to dynamically construct the target MCP server’s URL-encoded invocation endpoint. ### Step 3: Secure authentication with AgentCore Identity The Lambda authenticates using a two-step identity flow. It exchanges its execution identity for a temporary workload token. The Lambda then trades this token for a scoped OAuth bearer token through the target account’s credential provider. Credential providers are per-account (`CREDENTIAL_PROVIDER_{ACCT_ID}`), so one Lambda authenticates MCP servers across multiple accounts. ### Step 4: Query the MCP server Using standard MCP streamable-HTTP mechanics, the Lambda establishes an active session through an `initialize` request. After the session is active, it calls `tools/list` to fetch the complete array of currently exposed tools and schemas. ### Step 5: Find the matching registry record The Lambda queries the central Agent Registry to locate the corresponding record. It searches APPROVED records for one whose `mcpServer.data` contains the runtime ARN embedded during record creation (see the Deployment section).