ZICQ
中 Log in / Sign up
Newsroom Agentic #AWS Agent Registry #MCP #Amazon Bedrock AgentCore #Event-Driven Architecture #Tool Governance

AWS Automates Agent Registry Metadata Sync with Event-Driven Architecture

Avatar of Mr.Xu

By Mr.Xu Compiled & Reviewed by Editorial

Published:

中文阅读 (Chinese) English Version

Summary:AWS has published a deployable push-based pattern for keeping AWS Agent Registry synchronized with MCP server changes. CloudTrail captures Amazon Bedrock AgentCore runtime updates, Amazon EventBridge routes those events across accounts, and AWS Lambda retrieves the current tool definitions, compares their schemas, and updates matching registry records. AgentCore Identity supplies scoped OAuth tokens without storing client secrets in Lambda. The design preserves governance by returning modified


Technical core: turning catalog synchronization into an event pipeline

AWS's pattern is event-driven rather than polling-based. CloudTrail records UpdateAgentRuntime API calls as management events, EventBridge filters and routes those events, and Lambda connects to the target MCP Server, executes initialize and tools/list, and pushes the latest tool metadata into AWS Agent Registry.

Five components participate in the pipeline:

  • AWS CloudTrail captures AgentCore runtime changes;
  • Amazon EventBridge performs event filtering and single- or cross-account routing;
  • AWS Lambda queries the MCP Server, computes differences, and updates the registry;
  • AWS Agent Registry stores MCP Server records and tool schemas;
  • AgentCore Identity exchanges workload identity for OAuth access tokens.

The EventBridge rule matches source = aws.bedrock-agentcore, detail-type = API Call via AWS CloudTrail, and eventName = UpdateAgentRuntime. In the multi-account design, Account A owns the registry account, while Account B hosts the MCP runtime and Cognito OAuth provider.

Identity: a two-step exchange without stored client secrets

The Lambda does not store an OAuth client secret in its environment. It first calls get_workload_access_token to obtain a workload access token, then passes that token to get_resource_oauth2_token for an M2M OAuth exchange.

Credential providers and scopes are configured per target account, allowing one central Lambda to serve multiple MCP Server accounts. The Lambda still needs an IAM execution role, and every remote account must have the appropriate EventBridge resource policy, credential provider, and workload identity.

This reduces the exposure surface for long-lived secrets, but it does not eliminate credential risk. IAM permissions, workload identity conditions, OAuth scopes, and CloudTrail auditing remain the effective security boundary.

MCP discovery and diff computation

The function extracts the runtime ARN from responseElements.agentRuntimeArn and constructs the invocation URL from the ARN and AWS Region. It then sends a JSON-RPC initialize request. If the server returns Mcp-Session-Id, the value is included in the subsequent tools/list request.

The sample targets MCP Streamable HTTP with protocol version 2025-03-26. It rejects non-HTTPS URLs and applies a 30-second timeout. Its SSE parser also means production code must account for chunked responses, keep-alive events, proxy buffering, and server-initiated connection closure.

The diff contains only three normalized fields:

  • tool name;
  • tool description;
  • inputSchema.

Tools are sorted by name before comparison, preventing false updates caused only by response ordering. A mismatch triggers update_registry_record; an identical normalized list returns no_change.

Governance: synchronization does not equal publication

Registry records follow a Draft → Pending Approval → Approved lifecycle. After Lambda updates an approved record, it returns to Draft. Consumers continue seeing the previously approved version until an administrator approves the new metadata.

Automation therefore remains on the candidate-change side of the governance boundary. However, it does not remove the human approval burden. At larger registry sizes, finding pending changes, reviewing diffs, and approving them can become the next operational bottleneck.

Engineering trade-offs: freshness, latency, and reliability

The central trade-off is using CloudTrail audit events as the trigger. This avoids continuously polling every MCP Server, but CloudTrail delivery can take approximately 5–15 minutes. That may be acceptable for normal governance, but it is long for workflows that expect newly deployed tools to become discoverable immediately.

EventBridge can scale Lambda concurrency, but the post provides no throughput, concurrency, or cost measurements. The sample also lacks explicit idempotency keys and concurrent-write protection. A production implementation should use a content digest derived from the runtime ARN and tool definitions, so duplicate or out-of-order events cannot cause unnecessary writes.

Cold starts are the most important reliability gap. A newly initialized MCP Server may temporarily return an empty tool list. Treating that response as authoritative could erase the registry's previous tool definitions. The recommended mitigation is exponential backoff, zero-tool protection, and distinguishing a transient cold start from a genuine removal of all tools.

Registry lookup is also linear in the current implementation: the function lists records, fetches each full record, and matches ARN substrings. As the registry grows, this can increase API calls and latency. A deterministic ARN-to-record-ID index, along with concurrency control per record, would be more scalable.

Deployment guidance

The pattern fits teams that already run MCP Servers on Bedrock AgentCore and use Agent Registry for governed discovery. Required components include:

  • a Python 3.12 Lambda runtime;
  • an existing, approved MCP Server registry record;
  • an AgentCore Identity workload identity and OAuth2 credential provider;
  • cross-account EventBridge permissions;
  • the runtime ARN or invocation URL embedded in the initial registry record.

The current implementation updates existing records only; it does not automatically register unknown servers. It also requires a fresh approval after each metadata update. For time-sensitive deployments, an API Gateway or CLI force-sync path should complement CloudTrail's slower delivery route.

Scope of applicability

The architecture addresses metadata drift for MCP Servers already under management. It does not provide automatic onboarding, continuous health checks, rollback, documentation generation, or final-consistency validation between the registry and live runtime.

Its main contribution is connecting tool-catalog updates to an enterprise event and approval workflow using standard AWS services. Before production adoption, teams should add zero-tool safeguards, exponential backoff, idempotency, forced synchronization, and record-level concurrency controls.


Source: AWS Machine Learning Blog (2026-11-11)

— END —

Tags: #AWS Agent Registry #MCP #Amazon Bedrock AgentCore #Event-Driven Architecture #Tool Governance

Editorial & Fact-Checking Note: This article is compiled from primary research, official release documentation, and source papers by the ZICQ Newsroom pipeline with automated entity verification and human editorial review. If you notice any technical inaccuracy, please submit a correction via our corrections policy or email our editorial desk directly.

Community Comments

Loading live comments and annotations…