Authdog

MCP SDK

Last updated Oct 13, 2026
View as Markdown

Authdog ships two MCP server SDKs. They solve different problems and are not interchangeable, so pick by what your MCP server needs to enforce.

Token verifier SDKs MCP runtime guard
Source authdog/mcp-sdk packages/mcp-sdk in the Authdog monorepo
Languages Node.js, Python, Go, Rust, C#, Java, Kotlin, Swift, Dart TypeScript (Workers or Node)
Checks Is this bearer token valid, and who is the user Token against JWKS, trust store, per-tool AuthZEN decision, audit telemetry
Calls GET /v1/userinfo JWKS, trust store, AuthZEN, and POST /v1/mcp/events
Availability Source-available; registry publication unconfirmed Private; install from source

Token verifier SDKs

An MCP client obtains an Authdog access token, for example through MCP authentication, and sends it as a bearer token. AuthdogVerifier calls the environment's GET /v1/userinfo with that token and returns an AuthInfo:

  • subject, username, and email for the authenticated user
  • expiresAt, derived from the remaining session lifetime
  • scopes, currently always empty because userinfo does not return scopes yet
  • token and the full user object

A 401 from Authdog raises an authentication error your transport should turn into an HTTP 401. Any other failure raises a separate API error, so you can tell a rejected token from an unreachable Authdog.

Pick your language:

Language Guide Package
Node.js / TypeScript Node.js @authdog/mcp-sdk
Python Python authdog-mcp
Go Go github.com/authdog/mcp-sdk/go
Rust Rust authdog-mcp
C# C# Authdog.Mcp.Sdk
Java Java com.authdog:authdog-mcp-sdk
Kotlin Kotlin com.authdog:authdog-mcp-sdk
Swift Swift AuthdogMCP
Dart Dart authdog_mcp

MCP runtime guard

The TypeScript runtime SDK runs inside your MCP worker and layers four independent controls over each tool call. Adopt them one at a time:

  1. Authenticate: verify the caller's access token against your environment's JWKS, with RFC 9728 protected-resource metadata.
  2. Trust store: require the calling identity to be a verified non-human identity within its allowed scopes.
  3. Authorize: ask the AuthZEN decision point whether this identity may invoke this specific tool.
  4. Telemetry: emit invoked, denied, and failed events for audit and SIEM.

Trust store and authorization default to non-breaking modes (off and monitor). Move each to enforce after you have watched the decisions in the console. The package is private today, so install it from a clone of the monorepo.

import {
  authenticateRequest,
  checkTrustStore,
  createAuthdogTelemetry,
  withAuthdogToolGuard,
} from "@authdog/mcp-sdk"

const auth = await authenticateRequest(request, env)
if (!auth.ok) return new Response(auth.message, { status: auth.status })

const trust = await checkTrustStore(auth.claims, env)
if (!trust.ok) return new Response(trust.message, { status: trust.status })

const telemetry = createAuthdogTelemetry(env)
const readFile = withAuthdogToolGuard("my-server", "read_file", env, handler, {
  telemetry,
})

Configure it with these variables on your worker:

Variable Purpose
AUTHDOG_OIDC_ISSUER Environment OIDC issuer; JWKS is derived from it
AUTHDOG_OIDC_AUDIENCE Audience your tokens are minted for (your MCP server URL)
MCP_REQUIRED_SCOPES Space-separated scopes required on every call
AUTHDOG_API_BASE_URL Public API base, used by trust store, authorize, and telemetry
AUTHDOG_ENV_API_SECRET Environment API secret (adenv_...)
MCP_TRUST_STORE_MODE off (default), monitor, or enforce
MCP_AUTHZ_MODE off, monitor (default), or enforce
MCP_TELEMETRY true to emit tool-call events

AUTHDOG_DEV_MODE=true allows http://localhost issuers for local development. Never set it in production.

To detect a server changing its tools after registration, report a tool manifest hash with computeToolManifestHash and pin it on the trust-store entry.

Learn more