AWS teaches its MCP server registry to update itself: tool schemas with no manual edits

Every internal catalog dies the same way. At first it is accurate. Then someone adds a new function to a service and forgets to fix the entry, and a month later everyone goes to the code and the chat instead, because nobody trusts the catalog anymore. An MCP server registry has the same story, only the consequences are nastier: an agent may call a tool using an old schema and get confusing behavior with no explicit error.

AWS has published a walkthrough of how to prevent this in Agent Registry, part of Amazon Bedrock AgentCore. The idea is simple: updating a record should not depend on developer discipline. The deployment event itself should trigger it.

How it works

The chain of five services looks like this.

• A developer updates the MCP server, for example with the agentcore deploy command. This calls the UpdateAgentRuntime API, and CloudTrail records the call as a management event.
• EventBridge, using a rule (source aws.bedrock-agentcore, event name UpdateAgentRuntime), forwards the event to a central bus. In a multi-account setup, it lives in the registry account.
• Lambda extracts the runtime ARN from the event and builds the MCP server invocation URL from it. It takes the Region and account ID from the same ARN.
• Lambda obtains an OAuth token through AgentCore Identity: first a workload token for itself, then an M2M token from the credential provider of the relevant account. There are no client secrets in environment variables.
• Lambda calls initialize, then tools/list, and gets the current list of tools.
• It then looks for the registry record whose schema contains the same ARN (or an encoded ARN, or the URL) and compares the lists.

Where the engineering is neat

The comparison is designed to avoid unnecessary writes. Tools are sorted by name and reduced to three fields: name, description, and inputSchema. A write to the registry happens only if these fields differ, and the logs record exactly what was added or removed.

Two more useful details. Each account gets its own credential provider (a variable of the form CREDENTIAL_PROVIDER_{ACCT_ID}), so a single Lambda can serve servers from different accounts. And before making a request, the code checks that the URL starts with https://, which closes off nasty scenarios such as file://.

Imagine a payments team that adds a refund_status tool to its MCP server. Previously, the support team would have learned about it from the chat a week later. Now, 5–15 minutes after deployment, the registry record already contains the new tool with its current schema, and the Lambda logs show what changed.

Limitations worth knowing

First: the service does not create records. In the example, Lambda updates only records that are already registered, were created during onboarding, and contain the runtime ARN in mcpServer.data. Records in DRAFT status are skipped; APPROVED is required. This preserves the existing approval process, but initial registration will have to be automated separately.

Second: latency. CloudTrail delivers events in roughly 5–15 minutes, so this is not suitable for a "deploy and call immediately" scenario. For a catalog that people and agents read when searching for tools, such a lag is usually tolerable.

Third: the trigger is specifically UpdateAgentRuntime. If a server's set of tools changes dynamically without a runtime update, no event will fire, and records will have to be synced on a schedule.

There are also two observations about the code in the article itself. The record lookup iterates over the registry list and makes a separate get request for each item, and the snippet shown has no pagination. With dozens of servers this is fine; with hundreds, you should add an index or store the ARN-to-record-ID mapping separately. Part of the code in the original article is cut off, so it is better to look at the full version in the example repository.

What to do in practice

If you are building an internal MCP server catalog, adopt the whole pattern: deployment event, then tools/list polling, then diff, then write. It is not tied to AWS: on any cloud you can assemble the same thing from an audit log, an event bus, and a function. The main rule is this: the source of truth about the tool schema is the running server itself, and the catalog entry is merely its reflection, which must not be left to manual updates.