mcp-use advertises those endpoints and verifies the access-token JWTs.
Configure the MCP resource server
Pass the full Better Auth issuer URL, including its base path:/oauth2/authorize, /oauth2/token, /oauth2/register, and /jwks endpoints
from authURL, then verifies JWT issuer, signature, expiration, and MCP
resource audience.
Run Better Auth as a separate Hono app
The authorization server can be a separate application and origin. The normalmcp-use server above owns /mcp and its protected-resource metadata; the Hono
app only mounts Better Auth, its discovery routes, and your login and consent
pages.
/api/auth, also route Better Auth’s RFC 8414
path-insertion metadata endpoint
/.well-known/oauth-authorization-server/api/auth to auth.handler or
oauthProviderAuthServerMetadata(auth). Better Auth’s OAuth Provider guide
documents the required discovery, login, and consent routes. If browser-based
MCP clients call this separate origin directly, configure Hono CORS for the MCP
origin and include that origin in Better Auth’s trustedOrigins.
Credential-free anonymous example
The repository’s runnable example runs a regularmcp-use dev process on port 43127 and a separate Hono/Better
Auth process on port 61843. It uses anonymous sign-in, so it requires no
Google/GitHub credentials, email service, or password UI.
For easy local setup, the example omits a database. Better Auth then uses
stateless cookie sessions and its memory adapter. Anonymous users, dynamic
clients, codes, and consent reset whenever the process restarts; configure a
persistent Better Auth database before using the pattern in production.
Access the verified identity
customAccessTokenClaims. The built-in mapper recognizes email,
name, picture, email_verified, sid, is_anonymous/isAnonymous,
roles, and permissions when present.
Better Auth OAuth Provider
Configure Better Auth’s OAuth server, discovery routes, claims, and
persistence.