MCP registry

Pro-tier customers using IAM Identity Center can have MCP server access controlled through an MCP registry. When configured by administrators, users can only use MCP servers explicitly allowed in the registry.

Without Registry (default):

• Users can add any MCP server
• Servers configured in agent files or via CLI
• No central control

With Registry (enterprise):

• Administrator configures allowed servers
• Users select from registry list
• Cannot add custom servers - servers not in the registry are hidden, including ones you define yourself in mcp.json
• Centralized governance and security

When a registry is active, it is the only source of servers that can run. A server you define in mcp.json (global ~/.kiro/settings/mcp.json or workspace .kiro/settings/mcp.json) is eligible to run only if its name matches an entry in the registry. Anything else is hidden and never started, including servers that were working before the registry was turned on.

In the IDE, hidden servers appear as an "N servers hidden" notice in the MCP panel rather than as individual entries. To run a server that isn't in the registry, ask your administrator to add it.

In a Kiro CLI V3 session, a name match alone is not enough. A registry server runs only when its mcp.json entry is declared as {"type": "registry"}. An entry that matches a registry name but supplies its own command or url is skipped. The /mcp panel lists the configured servers the registry hid and, for servers the registry offers, shows how to declare them. kiro-cli mcp list marks these servers as skipped rather than active.

A mcp.json entry whose name is in the registry is still useful: it's how you supply values specific to your setup, such as API keys or local paths. See Registry server overrides.

Even with registry mode enabled, you can customize servers using registry overrides in your agent configuration or in an mcp.json file (global ~/.kiro/settings/mcp.json or workspace .kiro/settings/mcp.json). Your values are merged on top of registry defaults - for example, if the registry sets NODE_ENV=development and your override sets NODE_ENV=production, the server runs with NODE_ENV=production. The env and headers objects merge per-key, so registry defaults you don't override are preserved.

{
  "mcpServers": {
    "github": {
      "type": "registry",
      "env": {
        "GITHUB_TOKEN": "$GITHUB_TOKEN",
        "GITHUB_ORG": "my-org"
      },
      "timeout": 60000
    }
  }
}

Override fields:

• Local (stdio) servers - env (environment variables), timeout (request timeout in ms)
• Remote (HTTP) servers - headers (HTTP headers), timeout (request timeout in ms), oauth, and oauthScopes

The overrides you define for a registry-type entry flow through to the launched server, so the running process uses your customized values.

Kiro CLI V3 uses the oauth and oauthScopes settings supplied by an organization registry for remote servers. A matching registry override can replace those values for your local setup. These fields use the same format as remote servers in mcp.json. See OAuth authentication for the fields and scope rules.