AWS Agent Registry · MCP and agent discovery
AWS Agent Registry migration: move off bedrock-agentcore before September 17
AWS Agent Registry is now generally available under its own agent-registry namespace. Public-preview users have a hard migration boundary: AWS says the old registry surface under bedrock-agentcore shuts down on 17 September 2026. This is not only an endpoint rename — code, IAM, record schemas, observability and registry data all need attention.
zFinia published 12 September 2026 · migration deadline guide
Deadline
17 September 2026
AWS states that the public-preview registry namespace shuts down on this date. Any registry data left only in the old namespace will no longer be readable or writable there. New Registry integrations should already be built against the GA namespace.
What actually changes
| Surface | Preview | GA |
|---|---|---|
| Data-plane endpoint | bedrock-agentcore.{region}.amazonaws.com | agent-registry.{region}.api.aws |
| Control-plane endpoint | bedrock-agentcore-control.{region}.amazonaws.com | agent-registry-control.{region}.api.aws |
| IAM action prefix | bedrock-agentcore:* | agent-registry:* |
| Registry ARN namespace | arn:aws:bedrock-agentcore:... | arn:aws:agent-registry:... |
| CLI namespace | aws bedrock-agentcore | aws agent-registry |
AWS also calls out SDK client classes, service principals, Service Quotas, CloudTrail event sources, EventBridge sources and CloudWatch namespaces. Treat the migration as a dependency inventory, not a search-and-replace exercise.
The dangerous shortcut: replacing every bedrock-agentcore reference
The dedicated namespace applies to AWS Agent Registry only. AWS specifically notes that AgentCore workload identity and OAuth credential-provider resources remain underbedrock-agentcore. If your registry synchronizes an MCP server or A2A card from a protected URL, you can need both new agent-registry:*permissions and selected identity permissions in the old AgentCore namespace.
That makes a blind global rename risky. Inventory each reference by function: Registry control/data plane, or another AgentCore service that intentionally did not move.
Your record model changes too
GA introduces breaking schema changes. Registry records now require a uniquename and a semantic recordType such as AGENT,MCP, SKILL or CUSTOM. The descriptor structure is flatter, fields such as inlineContent become data, schema and protocol version fields converge on dataSchemaVersion, and synchronization configuration moves into descriptor-level source data.
Search changes as well: the preview SearchRegistryRecords operation becomesSearchDiscoverableRegistryRecords. GA also adds discoverable list and batch-get operations for building approved-record catalog experiences.
A migration checklist for the remaining window
- Inventory preview state. Record every registry, record count, region, writer, reader, IAM policy, stored ARN, endpoint override, SDK client, CLI script, infrastructure template and observability rule that touches Registry.
- Choose an AWS-supported migration path. AWS provides tooling that extracts preview data, transforms it to the GA schema and loads it into a new registry in the same account and region. Its guide separates small direct-script migrations, managed Lambda/Glue execution and dual-write migrations for actively changing production registries.
- Update namespace-dependent code and IAM deliberately. Move Registry endpoints, clients, CLI commands, ARNs and Registry permissions to
agent-registry, while retaining any AgentCore identity permissions that AWS says stay in the old namespace. - Transform record schemas. Do not assume the preview request/response model remains compatible. Validate required names, record types, descriptor keys, version fields and synchronization sources.
- Verify counts and content. AWS recommends comparing registry and record counts, spot-checking transformed descriptors and proving applications can read and write through the new namespace.
- Verify discovery, not just storage. An approved MCP or agent record should be discoverable through the GA search/browse APIs or the Registry MCP endpoint. A migrated record that exists but cannot be discovered is not a successful consumer cutover.
- Cut readers and writers over before the deadline. If you dual-write, remove the preview writer only after new-namespace reads and writes are proven. Do not make 17 September your first production test.
What GA discovery means for MCP servers and agents
AWS Agent Registry is a governed catalog, not a public internet directory. Consumers can search approved records with hybrid semantic and keyword search, browse approved records, retrieve full record details in batches, or access those discovery functions through the Registry's MCP-compatible endpoint.
Publishers can register MCP, agent, skill and custom record types. AWS can also synchronize metadata from an MCP server URL or A2A agent card, including protected sources when the required credential configuration is present. Approval remains the visibility boundary: non-approved records are not returned by the discoverable APIs.
Private registry discovery and public discovery are different layers
An AWS Agent Registry record helps authorized consumers inside the configured registry find approved resources. It does not replace provider-owned MCP metadata, the public MCP Registry, live endpoint verification or a stable machine-readable service contract. If external agents must also discover your server, maintain both layers intentionally.