Dynamic registration
You register most applications yourself. The provider also implements standard dynamic client registration (RFC 7591): software that speaks the protocol registers itself as a client, with nothing created first.
This is how a modern, interoperable tool expects to start. An MCP client reaching an MCP server you host behind this provider registers itself, sends the user through sign-in and consent, and works, with no administrator in between.
There you authenticate as the account holder through the panel's built-in mechanism, and no identity provider is involved. See MCP server.
Guardrails, not a switch
Dynamic registration is always on; there's no switch. Three limits control it instead:
- registration is rate-limited
- each provider holds at most 100 dynamic clients
- a client nobody uses is deleted: one week without an active sign-in, and it's removed. Leftover tests don't pile up.
This is what makes it safe. Users of a self-registered client go through the same sign-in, the same consent screen, and the same scope policies as an application you registered by hand. And only your own users can consent at all.
A self-registered client doesn't appear in your Applications list. It manages itself with the registration token it receives at creation.
When you register it yourself, you control its name and logo on the consent screen, it survives periods without use, and it shows in your Applications list.