The tools it ships are arithmetic — they are there so you can watch a token flow end to end. What you are actually adopting is the authorization layer: discovery, audience validation, the WWW-Authenticate handling on a 401, and a dashboard that shows failed attempts. If you are writing an MCP server that needs real auth, that is the expensive part, and this is a working version of it.
A Next.js project you deploy and then replace the tools in — an OAuth 2.1 server built to the MCP Authorization Specification, plus the monitoring you would otherwise have to add yourself. It is a starting point rather than a finished server.
- A complete OAuth 2.1 server with PKCE and refresh tokens, and dynamic client registration so MCP clients can onboard themselves
- Discovery endpoints implementing RFC 8414 and RFC 9728, resource indicators from RFC 8707, and strict token audience validation
- MCP endpoints over both SSE and HTTP, each requiring a bearer token that is checked against the database, its expiry and its audience
- An analytics dashboard with real-time request metrics, tool usage tracking and security event monitoring
- Six sample tools — `add_numbers`, `calculate_circle_area`, `generate_random_number`, `format_text`, `check_prime_number` and `trigger_security_events` — which exist to prove the flow and are meant to be swapped for your own
- Google sign-in through NextAuth, and PostgreSQL with automated cleanup and TTL management
Node with pnpm, a PostgreSQL database, and Prisma to generate the client and push the schema. Environment configuration is documented in the project's setup guide. It deploys to Vercel, and a live demo runs at mcp-oauth-sample.vercel.app, with the analytics dashboard restricted to an allowlist of Gmail addresses.
One command plus a key — npx -y mcp-remote https://your-domain.com/mcp/sse, then supply credentials