Dynamic Client Registration (RFC 7591)

Third-party MCP clients can register themselves without a person creating an OAuth app. Exayard's authorization server is Clerk, and Clerk hosts the registration endpoint. We don't run our own, and our metadata does not list it.

Discovery chain

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

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

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

Rules for registered clients

The rules for a client that registers itself (redirect URIs, grant types, PKCE) are the authorization server's. Exayard adds none of its own. Use the OAuth 2.1 authorization-code flow with PKCE.

After registration

Use the returned client_id (and client_secret, where the client type has one) in the authorization-code flow against the authorization server.

• Audience. Send resource=https://api.exayard.com in the authorization request. The MCP server refuses a token whose aud names another resource. A token with no aud is still accepted.
• It acts as the person. A client that registered itself is a personal connection: it acts as the person who signed in, in that person's companies, and that person can remove it at any time from their Developer page. See Personal connections.
• Which client. Exayard records the client id on each call's audit entry, so one client's activity can be told from another's. See Agent rate limits.

If you are building an integration that many companies install, register an app in Exayard instead: each company grants it scopes, and it can run with its keys when no person is present. See Authentication.