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.