Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@minion.town list all minions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A toy MCP (Model Context Protocol) server with OAuth 2.1 authentication and authorization, built to validate one design: an MCP server that has an excellent local developer experience and a clean path to AWS — with the same code running in both places, differing only by configuration.
It's a tiny "minion town": three MCP tools, each gated by an OAuth scope.
Full design rationale:
designs/mcp-oauth.md. AWS deploy:infra/README.md.
cp .env.example .env
npm install
npm run dev # mock OAuth server (:9000) + MCP server (:3000), hot-reloadIn another terminal, run the full OAuth + MCP flow:
npm run client # PKCE flow → every tool succeeds
npm run client -- read-only # omit the write scope → summon_minion is denied→ running OAuth flow (scope: mcp:tools mcp:minions:read mcp:minions:write)
✓ got access token (eyJraWQiOiI0NjY5…)
tools: minion_status, list_minions, summon_minion
minion_status: ✓ 🏙️ minion.town has 0 minion(s).
summon_minion: ✓ ✨ Summoned Bob (minion-1) to do "guard the gate".
list_minions: ✓ • Bob — guard the gateRun the end-to-end authN/authZ tests (real mock AS + real middleware, nothing about the auth path is stubbed):
npm testRelated MCP server: Keycard Hello MCP Server
Tool | Scope required | Does |
|
| count minions in town |
|
| list the roster |
|
| summon a new minion |
A token only carrying mcp:tools mcp:minions:read can list but cannot
summon — authorization is enforced from the token's scopes.
The MCP server is an OAuth 2.1 resource server. Unauthenticated requests get
401 + WWW-Authenticate pointing at RFC 9728 Protected Resource Metadata,
which advertises the authorization server. The client runs PKCE auth-code
with an RFC 8707 resource parameter; the server validates the JWT's
signature, issuer, expiry, and audience (so a token for another server is
rejected), then maps the token's scopes → which tools it may call. Locally
the authorization server is oauth2-mock-server;
on AWS it's Amazon Cognito. The server code is identical; only src/config.ts
reads different env vars. Built on @modelcontextprotocol/sdk and grounded in
the MCP authorization spec (2025-06-18 + Nov 2025 update).
src/ MCP resource server (config seam, verifier, scope→tool map, tools, HTTP)
dev/ local dev harness: mock OAuth AS + browserless PKCE client
test/ end-to-end authN/authZ tests
infra/ AWS CDK deploy (App Runner + Cognito + Route53/ACM) — documented path
designs/ the design documentNo secrets are committed. .env is gitignored; AWS secrets are injected by the
platform. See designs/mcp-oauth.md § Threat-model notes.
This server cannot be deployed
Self-hosted federated MCP gateway: one OAuth 2.1 MCP server in front of N apps, user-level scopes.
The Stytch MCP server is a reference implementation that demonstrates remote MCP server authentication and authorization using Stytch Connected Apps. It provides OAuth 2.1-compliant authorization (including PKCE), Dynamic Client Registration, and validates Stytch-issued access tokens to enable AI agents to securely interact with external services through permissioned access, supporting scopes like openid, email, profile, and manage:project_data.
