Announcing CIMD Support for MCP Client Registration

MCP adoption has accelerated quickly over the past few months. What started as early experimentation across IDEs and agents is now showing up in production-grade workflows — from internal developer tools to SaaS platforms exposing MCP servers.

As MCP usage grows, client registration has become a real, practical problem.

MCP servers are no longer talking to a small, fixed set of known clients. Instead, they’re seeing connections from IDEs, desktop hosts, internal tools, and agent runtimes — many of which are installed locally or discovered dynamically. Traditional client registration models don’t always fit cleanly into this world.
‍

To support this shift, the MCP authorization work has introduced Client ID Metadata Documents (CIMD) — a model where a client can identify itself using a metadata URL instead of relying on pre-registered credentials or Dynamic Client Registration (DCR).

Today, we’re announcing first-class CIMD support in Scalekit.

The problem: MCP client registration doesn’t scale cleanly

In classic OAuth setups, client registration is usually handled in one of two ways:

• Manual pre-registration, where every client is defined ahead of time
• Dynamic Client Registration (DCR), where clients programmatically register themselves

Both approaches work well in controlled environments. But MCP introduces new realities:

• Clients may be unknown ahead of time
• Many MCP clients run locally (IDEs, desktop tools)
• MCP servers may be public or ecosystem-facing
• Operators don’t always want to expose an open /register endpoint or manage client state for every tool

Without CIMD, MCP clients either reuse static OAuth clients (which is unsafe) or hand-roll dynamic registration flows that break across sessions and tools. CIMD standardizes how ephemeral clients declare intent and metadata, exactly what MCP clients need.

As a result, MCP server operators need a registration model that’s more flexible — without giving up safety or correctness.

What CIMD changes

Client ID Metadata Documents (CIMD) take a different approach.

Instead of issuing a static client ID or registering one dynamically, a CIMD-compatible client uses an HTTPS URL as its client identifier. That URL resolves to a metadata document describing the client (for example, its redirect URIs and name).

At authentication time, the authorization server fetches this metadata and uses it to drive the OAuth flow.

This model works particularly well for MCP environments where clients are diverse, distributed, and not always known in advance — while still preserving explicit metadata and validation during authentication.

‍What we shipped: CIMD support in Scalekit

Scalekit now supports registration via metadata URL (CIMD) for MCP clients.

When a CIMD-compatible MCP client initiates authentication against an MCP server secured by Scalekit:

1. The client supplies a metadata URL as its client_id
2. Scalekit fetches the client metadata from that URL
3. The OAuth flow proceeds using the resolved metadata

From the MCP server’s perspective, this provides an additional registration mode alongside:

• Automatic registration via DCR, supported by many popular MCP clients
• Manual pre-registration, for tightly controlled or custom clients
• Metadata URL–based registration (CIMD), now supported by Scalekit

CIMD doesn’t replace existing models — it gives you another option that fits open or dynamic MCP environments better.

What Scalekit handles for you

Implementing CIMD correctly involves more than just fetching a JSON file.

With Scalekit’s CIMD support, you don’t have to build or maintain:

• Runtime fetching of client metadata
• Validation of client metadata during OAuth flows
• Redirect URI validation across dynamically identified clients
• Operational plumbing to support multiple client registration modes

CIMD becomes a supported, production-ready registration option rather than a custom implementation you need to harden yourself.

When should you use CIMD?

CIMD is a good fit when:

• You expect MCP clients you don’t fully control ahead of time
• You’re building ecosystem-facing or developer-focused MCP servers
• You want to avoid managing client records or exposing open registration endpoints

DCR and manual registration remain valid — and often preferable — in more controlled environments. Scalekit supports all three, so you can choose what fits your MCP deployment.

Getting started with CIMD in Scalekit

Enabling CIMD for an MCP server in Scalekit is intentionally simple:

• Open your MCP server configuration in the Scalekit dashboard
• Enable CIMD registration (it’s a single checkbox)
• Save — Scalekit will handle CIMD-based client registration during authentication

There’s no additional setup required on the server side.

Learn more with CIMD docs.

FAQs

What is CIMD and how does it benefit MCP?

CIMD stands for Client ID Metadata Documents. It allows MCP clients to identify themselves using a metadata URL instead of traditional pre-registered credentials. This model is ideal for dynamic environments like IDEs or local agent runtimes where clients are not known ahead of time. By resolving metadata at runtime, Scalekit enables secure authentication without the overhead of manual registration or managing state for every ephemeral tool. It simplifies the connection between diverse clients and MCP servers while maintaining strict validation of redirect URIs and client identities during the OAuth flow.

How does CIMD differ from Dynamic Client Registration?

Traditional Dynamic Client Registration requires clients to programmatically register and receive a unique ID, often necessitating an open registration endpoint. In contrast, CIMD uses an HTTPS URL as the client identifier directly. The authorization server fetches the necessary metadata from this URL during the authentication process. This approach eliminates the need to manage persistent client records or expose vulnerable registration endpoints to the public. For MCP environments, CIMD provides a more scalable and less complex alternative to DCR, especially when dealing with ecosystem-facing servers and a wide variety of local developer tools.

Why is manual client registration difficult for MCP servers?

Manual registration assumes a controlled environment where every client is known and configured in advance. MCP servers often interact with a broad array of tools, including desktop hosts, IDE extensions, and internal agent runtimes. Manually managing credentials for these diverse and frequently changing clients creates significant operational friction. It hinders developer productivity and limits the flexibility of the MCP ecosystem. Scalekit addresses this by supporting CIMD, allowing servers to securely authenticate unknown clients by resolving their metadata on demand, thus removing the bottleneck of manual pre-configuration while ensuring robust security standards.

What security validation does Scalekit perform for CIMD?

When a client initiates authentication using a CIMD URL, Scalekit performs several critical security functions. It fetches the metadata document from the provided HTTPS URL and validates its contents, ensuring the client identity and redirect URIs are legitimate. This runtime validation prevents common OAuth vulnerabilities like redirect URI manipulation. Scalekit handles the operational plumbing of fetching, parsing, and verifying this metadata, so you do not have to build custom hardening logic. This ensures that even in dynamic MCP environments, every authentication request is backed by verified metadata, maintaining a high security posture for your B2B applications.

When should developers choose CIMD over traditional methods?

CIMD is the preferred choice when you expect to encounter MCP clients that you cannot control or pre-register. It is particularly effective for building ecosystem-facing servers or developer-focused platforms where users bring their own tools. If you want to avoid the complexity of managing thousands of client records or the security risks of an open registration endpoint, CIMD provides a clean middle ground. However, for highly controlled internal environments where clients are static, manual registration might still be appropriate. Scalekit allows you to enable all three modes, giving you maximum flexibility for any deployment scenario.

How do I enable CIMD support within Scalekit?

Enabling CIMD support in Scalekit is designed to be a frictionless process for engineering teams. You simply navigate to your MCP server configuration within the Scalekit dashboard and select the CIMD registration checkbox. Once saved, Scalekit automatically begins handling CIMD-based client registration during the OAuth flow. There is no need for additional server-side code or complex infrastructure changes. This abstraction allows you to focus on building your MCP server logic while Scalekit manages the intricacies of metadata fetching, validation, and authentication across various registration models including DCR and manual setup.

Can CIMD coexist with other client registration models?

Yes, CIMD is designed to complement existing registration models rather than replace them. Scalekit supports a multi-modal approach where you can offer manual pre-registration, Dynamic Client Registration, and CIMD simultaneously. This flexibility allows you to cater to different types of clients. For example, you might use manual registration for your own internal tools, DCR for established partner integrations, and CIMD for the broader ecosystem of independent developer tools and agents. This ensures that your MCP server remains accessible and secure regardless of how the connecting client prefers to identify itself during authentication.

What specific MCP problems does CIMD solve?

MCP clients often run locally in IDEs or ephemeral agent runtimes, making traditional credential management impractical. Without CIMD, developers often resort to reusing static OAuth clients, which is a major security risk, or building fragile custom registration flows. CIMD standardizes how these diverse clients declare their intent and metadata using a simple URL. It solves the scalability problem of client registration by allowing the authorization server to resolve client details dynamically. This ensures that MCP servers can interact safely with a wide range of tools without requiring burdensome administrative overhead or compromising on authentication security.

Does CIMD improve the user experience for developers?

CIMD significantly enhances the developer experience by removing the barriers to connecting new tools to MCP servers. Developers no longer need to navigate complex registration portals or manage long-lived secrets for every local tool they use. By simply providing a metadata URL, the authentication process becomes seamless and automated. This frictionless setup encourages adoption of MCP-based workflows and tools within the developer community. Since Scalekit handles the underlying complexity of the CIMD specification, developers can integrate these capabilities into their platforms quickly, providing a modern and secure authentication experience for their end users and agentic applications.

‍