Dynamic Client Registration (RFC 7591)

Third-party MCP clients register themselves without a human creating an OAuth app. Exayard's authorization server is Clerk, and Clerk hosts the DCR endpoint — we don't run our own.

Discovery chain

MCP clients find the registration endpoint through the standard two-hop chain:

1. Hit our protected-resource metadata: https://api.exayard.com/.well-known/oauth-protected-resource. Read authorization_servers[0].
2. Hit that authorization server's metadata at <auth-server>/.well-known/oauth-authorization-server. Read registration_endpoint.
3. POST the RFC 7591 client metadata to that endpoint.

Most MCP clients do all three hops automatically — you don't write any of this by hand.

Constraints that still apply

The authorization server enforces the usual RFC 7591 / OAuth 2.1 rules:

• redirect_uris must be https://… or http://localhost… (RFC 8252 for installed apps)
• Only authorization_code + refresh_token grant types
• Only response_type: code (OAuth 2.1 removes the legacy flows)
• PKCE is mandatory

After registration

Use the returned client_id (and client_secret where the client type requires one) in the OAuth 2.1 authorization-code + PKCE flow against the authorization server. Tokens come back with an aud claim for https://api.exayard.com and carry the client_id in their claims — we read that as the caller's agentClientId, so audit logs can distinguish one MCP client's activity from another. See Agent rate limits.