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, andemailfor the authenticated userexpiresAt, derived from the remaining session lifetimescopes, currently always empty because userinfo does not return scopes yettokenand the fulluserobject
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:
- Authenticate: verify the caller's access token against your environment's JWKS, with RFC 9728 protected-resource metadata.
- Trust store: require the calling identity to be a verified non-human identity within its allowed scopes.
- Authorize: ask the AuthZEN decision point whether this identity may invoke this specific tool.
- 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.