An **MCP server** is a project type in Authdog for Model Context Protocol servers, the endpoints AI agents call to use your tools. Registering one gives the server OAuth-based authentication, so an agent has to prove who it is (and who it is acting for) before it can call a tool.

Create one from the [Projects hub](/docs/console/projects) by choosing **MCP server** in the Create application dialog: _"Expose tools and resources to AI agents securely."_

## What you get

- Register a Model Context Protocol server for AI agents
- Secure, authenticated tool and resource access
- Manage scopes and access control after creation

MCP projects appear in the Projects hub with an **MCP** type badge and their transport as a subtitle, for example `SSE transport`. They filter under the **MCP** tab in the rail.

## The MCP Auth module

Selecting an MCP project adds an **MCP Auth** entry to the **Products** group in the sidebar. It does not appear for web or M2M projects.

![MCP Auth Playground](/content/console/mcp.auth-playground.png)

The module opens on the **MCP Auth Playground**, which lets you exercise the auth path end to end without writing a client.

### Playground

| Element | Purpose |
|---------|---------|
| **Server selector** | Picks which registered MCP server to test against. |
| **Status badge** | `Idle` until you connect. |
| **Connect with SSO** | _"Use SSO to mint short-lived bearer for this environment."_ |
| **Endpoint & Bearer** | The resolved endpoint and the minted bearer token. |
| **IDENTITY** | Who the token represents, your console user, the environment, and whether an MCP token has been issued. |
| **TOOL ACCESS** | **Import tools** discovers the server's tool list. Disabled until you connect: _"Connect with SSO first."_ |
| **Advanced** | Additional request options. |

The order matters: **Connect with SSO** first to mint the bearer, then **Import tools** to enumerate what the server exposes. Until then the identity panel reads **No MCP token**.

> **Tip**
>
> Tokens minted in the playground are short-lived and scoped to the selected
> environment. Use a `dev` environment while iterating on a tool's scopes, and
> only point the playground at `prod` when you are verifying a release.

## Configuring an MCP server

The rest of the console works the same for MCP projects as for any other:

| To configure | Go to |
|--------------|-------|
| Clients and scopes | [Authentication > Clients](/docs/console/authentication) |
| Which agents may call which tools | [Authorization](/docs/console/authorization) |
| Tool-call history | [Audit](/docs/console/audit) |
| Abuse detection on the auth surface | [Lidar](/docs/console/lidar) |
| Server credentials | [Vault](/docs/console/vault) |
| Environments and transport URL | [Project settings](/docs/console/settings) |

Each MCP project can carry several environments, so a server can expose a staging tool set separately from production.

## MCP security

Beyond authenticating agents, Authdog secures the tools they call. These
controls ship in the [`@authdog/mcp-sdk`](/docs/machine-identity) that runs
inside your MCP server, and each is opt-in to adopt gradually.

| Control | What it does |
|---------|-------------|
| **Trust store** | An environment-scoped registry of the non-human identities (agents, MCP servers, workloads) allowed to reach your server. Only **verified** entries may call tools when enforcement is on; revoking one is an instant kill switch. Manage it under **Lidar > Trust Store**. |
| **Per-tool authorization** | Each tool call is checked against the identity's allowed tools through Authdog's authorization engine, an agent gets exactly the tools you granted, nothing more. |
| **Tool-call audit** | Every invocation, denial, and failure is recorded (agent, tool, decision, duration, never raw arguments) and flows to your [Audit](/docs/console/audit) trail and any [SIEM channel](/docs/console/notifications). |
| **Threat detection** | Detectors for tool poisoning, prompt injection, data exfiltration, rate abuse, and rug pulls (a server changing its tools after registration) surface as [Lidar](/docs/console/lidar) signals. Gated like Lidar, request access from the console. |

> **Tip**
>
> Start each control in monitor mode and watch the decisions in the console
> before switching to enforce, so a misconfiguration never breaks a live agent.

## Authdog's own MCP server

Authdog also publishes an MCP server for managing Authdog itself, reading users, counting them, setting the active user, and updating profiles from an agent. Actions taken through it are attributed distinctly from console actions in the audit trail, to tell agent-driven changes from human ones.

## Related

| Read | To learn how to |
|------|-----------------|
| [Projects](/docs/console/projects) | Register an MCP server project |
| [Authentication](/docs/console/authentication) | Manage the OpenID clients agents authenticate with |
| [Authorization](/docs/console/authorization) | Scope which tools an agent may call |
| [Audit](/docs/console/audit) | Review agent activity |
| [Machine identity](/docs/machine-identity) | Understand the client credentials grant |