Analysing the existing auth.js or next-auth setup and producing a plan from it is the part that is hard to do by hand and easy to get wrong halfway through. The testing tools matter for the same reason: after a migration the failure mode is a flow that still works for the happy path and silently broke password reset or 2FA, and those are exactly the flows this exercises.
An MCP server aimed at projects moving onto Better-Auth. It reads a project's structure and its existing auth.js or next-auth implementation, produces a step-by-step migration plan, configures providers, and then tests the resulting flows and checks them against OWASP-aligned rules.
- A project read for what its auth setup should be, and the auth it already has detected in place — `analyze_project`, `analyze_current_auth`
- A step-by-step path off the current implementation, taking the current auth type as input — `generate_migration_plan`
- Auth providers configured against a project id and API key — `setup_better_auth`
- Login, register, reset and 2FA flows exercised, and OWASP-aligned security checks run over the result — `test_auth_flows`, `test_security`
- Auth system logs reviewed for problems, and authentication activity watched as it happens — `analyze_logs`, `monitor_auth_flows`
- Two resources to read directly: the current configuration at `better-auth://config` and the logs at `better-auth://logs`
A Better-Auth project id and API key, supplied as `BETTER_AUTH_PROJECT_ID` and `BETTER_AUTH_API_KEY`. `BETTER_AUTH_ENV` selects development, staging or production and `LOG_LEVEL` sets verbosity; both are optional. The npm package name is `better-auth-mcp-server` (0.1.0) and it is marked private, so install from a clone with `npm install` and `npm run build`, or through the Smithery installer. Use a different API key per environment, since the same key reaches whatever that environment's auth configuration is.
One command plus a key — npx -y @smithery/cli install @nahmanmate/better-auth-mcp-server --client claude, then supply credentials