OAuth (Dynamic Client Registration)

TKP's MCP server implements the standard MCP OAuth flow: a client that supports "remote MCP server with OAuth" needs nothing but the server URL. It discovers everything else (authorization endpoint, token endpoint, registration endpoint) from:

{APP_URL}/.well-known/oauth-protected-resource
{APP_URL}/.well-known/oauth-authorization-server

What happens when you connect a client this way

1. Point the client at {APP_URL}/mcp. No client ID, secret, or manual app registration needed up front.
2. The client registers itself against {APP_URL}/oauth/register (Dynamic Client Registration, RFC 7591). This happens automatically, without you doing anything.
3. A browser window opens asking you to sign in to TKP (if you aren't already) and then authorize the application. You'll see which workspace the connection will use and a permissions screen, the same library/ability picker described in Permissions & abilities, where you choose exactly what this client may access. Nothing is granted until you approve this screen.
4. The client receives an access and refresh token and starts using /mcp.

Managing a connected app afterwards

Every application you've authorized this way shows up under Settings → Connected Apps. From there you can:

• adjust its interfaces and abilities without reconnecting it,
• or disconnect it, which immediately revokes its access and refresh tokens (your own browser session is unaffected).

When to prefer this over an API key

OAuth is the better default when your client supports it: nothing to copy, paste, or leak in a config file, and revoking access is one click away in the admin panel rather than hunting down and deleting a token. Use an API key instead when the client can't do an OAuth redirect (headless scripts, some coding-agent configs) or when you want a credential you can drop straight into an environment variable.