Build an MCP server

Your MCP server is the resource. Authdog is the authorization server. A tool runs only after you accept the bearer, and only if that caller may use that tool.

Authdog's own MCP server is a different process. It manages the Authdog account. This page is the server you ship.

Pick the check

The Python sample uses token_verifier and userinfo. It does not install the runtime guard. Add the guard when you want allowed-tool globs and MCP_TOOL_DENIED in the audit log.

@authdog/mcp-sdk (the runtime package) is source-only in packages/mcp-sdk. It is not on npm. The language verifier packages are source-available in authdog/mcp-sdk.

Register the server

In the console, create a project and choose MCP server. MCP Auth shows up in the sidebar for that project type. Enable it under MCP Auth → Settings, and set the default resource if clients omit resource.

The playground mints a bearer for your console session and calls a tool. A successful playground call proves that session can invoke that tool. It does not authorize every agent in the trust store. Register those in Agents.

Turn on enforcement

The runtime guard defaults to modes you can watch before you block:

1. Authenticate the access token against the environment JWKS.
2. Require a verified non-human identity when the caller is an agent.
3. Ask AuthZEN whether this identity may invoke this tool.
4. Emit invoked, denied, and failed events.

Move trust store and authorization to enforce after you have watched the decisions. Happy path in production is enforce. off and monitor are for staging.

Issuer revoke stops new tokens when the subject is the OIDC client id. Tokens already issued last until expires_in unless the resource server enforces the trust store.

Related