Dynamic Registration & Scope Design

Dynamic client registration (RFC 7591) allows MCP clients to register with a server programmatically, without a manual setup step. The client sends a POST to the registration endpoint with its metadata (name, redirect URIs, grant types, logo URI) and receives a client_id and optionally a client_secret. This is critical for MCP because clients are often tools that users install from a marketplace — requiring manual registration for each server/client pair does not scale. The registration endpoint itself may be open (any client can register) or protected (requiring an initial access token from an administrator).

Scope design for MCP servers requires thinking in capabilities, not permissions. A good scope hierarchy starts broad (tools:execute) and narrows by category (tools:execute:filesystem, tools:execute:database, tools:execute:network). Each scope should map to a human-readable description on the consent screen. Avoid scope explosion — 50 granular scopes overwhelm users on the consent screen. Group related capabilities under a single scope (resources:read covers all resources) and use tool-level authorization for fine-grained control within the scope. The scope gets the user in the door; tool-level policies decide what they can do inside.

Scope validation must happen at two points: at the authorization endpoint (the server checks that the requested scopes are valid and the user has permission to grant them) and at the resource endpoint (the server checks that the access token's scopes include the capability needed for the current request). The second check is where most implementations fail. It is not enough to validate scopes when issuing the token — you must re-validate on every request because scopes can be narrowed by the user during consent (they might deselect "tools:execute:filesystem" on the consent screen).

1. Implement the registration endpoint Accept POST requests with client metadata (client_name, redirect_uris, grant_types, token_endpoint_auth_method). Return a client_id. For public clients, do not issue a client_secret. Store registrations in a database, not in-memory.
2. Design your scope hierarchy List every capability your server offers. Group them into 5-10 scopes. Write a one-sentence human description for each. Map each scope to the tools and resources it governs.
3. Enforce scopes at the resource layer On every tool invocation and resource read, extract the token's scopes and check against the required scope. Return 403 (insufficient scope) if the check fails. Never rely solely on the authorization endpoint check.