An MCP client is the app that wants to call tools: Claude, Cursor, or a product you ship. It discovers Authdog from your server's `401`, signs the user in, and sends the access token on the next call.

Connecting a coding agent to [Authdog's management MCP](/docs/ai/mcp-server) is a different URL (`https://api.authdog.com/mcp`) and a different install command.

## What the client does

1. It calls your MCP server without a token.
2. Your server responds with **401** and `WWW-Authenticate` pointing at protected-resource metadata.
3. The client loads that metadata, starts authorize with **PKCE (S256)**, and can send a **resource** indicator (RFC 8707).
4. After consent, the client exchanges the code at the token endpoint and calls tools with `Authorization: Bearer`.

```text
Client --(no token)--> your MCP server
Server --401 + resource_metadata--> Client
Client --authorize + PKCE--> Authdog
Client --token--> Authdog
Client --Bearer token--> your MCP server
```

Your server still has to verify that bearer. Discovery does not do it. See [Build an MCP server](/docs/ai/mcp-development/build-server).

## What you turn on

In **MCP Auth → Settings** for the MCP project's environment:

- **Enable MCP Auth** turns on default-resource and strict-resource behavior for that issuer.
- **Default resource** applies when the client omits `resource`.
- **Strict resource mode** rejects authorize and token requests that omit `resource` when no default is set.

Dynamic client registration and client-ID metadata (CIMD) are per environment. When MCP Auth is enabled, the issuer registration endpoint honors those toggles. A CIMD client uses an `https` metadata URL as `client_id`.

Hosted consent, enterprise SSO, and session policy are the same issuer as the rest of the environment. There is no separate MCP-only identity provider.

## Agent callers

A person going through that login gets a user token. An unattended agent usually presents a `client_credentials` token instead, minted the way [API keys and M2M for MCP](/docs/ai/mcp/api-keys-and-m2m) describes. The verifier on your server accepts either, as long as userinfo accepts the bearer. Tool authorization is the next check.

## Related

| Read | To learn how to |
| --- | --- |
| [MCP authentication](/docs/mcp-authentication) | Read metadata, consent, revocation, and SIEM forwarding |
| [Build an MCP server](/docs/ai/mcp-development/build-server) | Verify the token the client just sent |
| [Use Authdog's MCP server](/docs/ai/mcp-server) | Connect a coding agent to the control plane |
| [MCP servers](/docs/console/mcp) | Find Settings and the playground |