Provides authentication provider configuration and integration setup for Apple Sign-In
Provides database adapter configuration for Drizzle ORM integration with Better Auth
Provides framework-specific authentication setup guides and integration examples for Expo applications
Provides authentication provider configuration and integration setup for Facebook Login
Provides authentication provider configuration and integration setup for GitHub OAuth
Provides authentication provider configuration and integration setup for Google Sign-In
Provides database adapter configuration for MongoDB integration with Better Auth
Provides database adapter configuration for MySQL integration with Better Auth
Provides framework-specific authentication setup guides and integration examples for Next.js applications
Provides framework-specific authentication setup guides and integration examples for Nuxt applications
Provides database adapter configuration for PostgreSQL integration with Better Auth
Provides database adapter configuration for Prisma ORM integration with Better Auth
Provides framework-specific authentication setup guides and integration examples for Remix applications
Provides database adapter configuration for SQLite integration with Better Auth
Provides framework-specific authentication setup guides and integration examples for SvelteKit applications
Generates TypeScript authentication configuration code with type-safe schemas and validation
Provides plugin configuration and setup for WebAuthn/FIDO2 passwordless authentication and passkeys
Uses Zod for validation of authentication configurations and schema definitions
Click on "Install 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., "@Better Auth MCP Server generate a Next.js auth config with Google and GitHub providers"
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 modern Model Context Protocol (MCP) server for the Better Auth authentication framework.
This server provides developer-friendly tools, searchable documentation, ready-to-use integrations, and configuration generators for authentication providers, database adapters, and plugins.
📚 Full Documentation Access – categorized, searchable, and framework-specific examples
🔐 Authentication Providers – Email/Password, Google, GitHub, Apple, Microsoft, Facebook, and more
🗄️ Database Adapters – PostgreSQL, MySQL, SQLite, MongoDB, Prisma, Drizzle
🔧 Plugins & Extensions – OTP, Magic Link, 2FA, Passkey, Organization Management, API Tokens
⚙️ Smart Tools – Config generation, validation, migration guides, and framework integration
🔒 Security Built-in – CSRF protection, secure cookies, rate limiting, WebAuthn/Passkeys, 2FA
Related MCP server: MCP Developer Server
npx -y @smithery/cli install @dabhivijay2478/auth --client claudegit clone <repository-url>
cd better-auth-mcp-server
npm install
npm run buildUpdate claude_desktop_config.json:
{
"mcpServers": {
"better-auth": {
"command": "node",
"args": ["path/to/dist/index.js"],
"env": {
"NODE_ENV": "production"
}
}
}
}list_better_auth_features – List all available features and plugins
get_feature_details – Get details for a specific feature or plugin
search_better_auth – Search Better Auth documentation
get_integration_guide – Framework-specific setup (Next.js, Nuxt, Remix, SvelteKit, Expo, etc.)
get_auth_examples – Code snippets and usage examples
target_llms_context – Access Better Auth LLMs.txt for comprehensive context
const setup = await generate_auth_config({
providers: ["email-password", "google", "github"],
adapter: "postgresql",
plugins: ["magic-link", "two-factor"],
framework: "nextjs"
});
console.log(setup.serverConfig);const google = await get_auth_provider_config({ provider_name: "google" });
console.log(google.setupSteps);const validation = await validate_auth_setup({
config: "your auth.ts config here",
framework: "nextjs"
});
console.log(validation);CSRF Protection – Safe request handling
Session Security – Rotation, expiration, validation
Passkeys & WebAuthn – FIDO2 support
Two-Factor Auth – TOTP, backup codes
Rate Limiting – Prevent abuse
Password Security – Strong hashing and validation
Language: TypeScript (ES2022 target)
Validation: Zod schemas
Protocol: Model Context Protocol (MCP)
Code Generation: Production-ready configs and migration scripts
Error Handling: Detailed and recoverable
Clone repo
Install dependencies: npm install
Build: npm run build
Update src/index.ts with new features
When Better Auth adds features:
Extend AUTH_PROVIDERS, DATABASE_ADAPTERS, PLUGINS
Add documentation mappings
Write tool handlers
Test thoroughly
MIT License – see LICENSE file
Get usage examples and code snippets for Better Auth features
| Name | Required | Description | Default |
|---|---|---|---|
| featureName | Yes | Feature to get examples for (e.g., "email-password", "github", "two-factor") | |
| framework | No | Optional framework filter for examples |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves examples and snippets, implying a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication requirements, or response formats. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage guidelines, and output expectations. Without annotations or an output schema, more context would be beneficial for the agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('featureName' and 'framework'). The description adds no additional meaning beyond what the schema provides, such as example values or usage context. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('usage examples and code snippets for Better Auth features'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_feature_details' or 'get_integration_guide', which might also provide related information about features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_feature_details' or 'search_better_auth', nor does it specify contexts or exclusions for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Better Auth plugin or feature
| Name | Required | Description | Default |
|---|---|---|---|
| featureName | Yes | Name of the Better Auth feature (e.g., "two-factor", "github", "drizzle") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' information, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured or unstructured data, or handles errors. For a tool with no annotations, this leaves key behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. There's no wasted verbiage or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it fails to explain what the detailed information includes (e.g., documentation, configuration options, status). For a tool named 'get_feature_details', more context on the output would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'featureName' clearly documented as the name of the Better Auth feature. The description doesn't add any extra meaning beyond what the schema provides, such as examples beyond those in the schema or constraints on valid feature names. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific Better Auth plugin or feature', making the purpose understandable. However, it doesn't explicitly distinguish this tool from its sibling 'list_better_auth_features' (which likely lists features without details) or 'search_better_auth' (which might search across features), leaving some ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or exclusions, such as whether it's for retrieving metadata, documentation, or operational details. With multiple sibling tools available, this lack of comparative guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get integration guide for a specific framework or platform
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Framework name (e.g., "next", "remix", "astro", "expo") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe any behavioral traits such as whether this is a read-only operation, if it requires authentication, potential rate limits, error handling, or the format of the returned guide. This leaves significant gaps for an AI agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly states what the tool does, making it easy to parse and understand quickly. Every part of the sentence earns its place by specifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety or performance, nor does it hint at the return format (e.g., whether it's a document, link, or structured data). For a tool with no structured support, the description should provide more context to compensate, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'framework' parameter well-documented in the schema. The description adds no additional meaning beyond what the schema provides, such as examples of frameworks not listed or context about how the framework name is used. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('integration guide') with specificity about the target ('for a specific framework or platform'). It distinguishes the tool's purpose from siblings like 'get_auth_examples' or 'get_feature_details' by focusing on integration guides. However, it doesn't explicitly differentiate from 'get_llms_context' or 'search_better_auth', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or exclusions. For example, it doesn't clarify if this is for initial setup versus troubleshooting, or when to choose 'get_integration_guide' over 'list_better_auth_features' or 'search_better_auth' for related information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Better Auth LLMs.txt content for comprehensive context
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'gets' content, implying a read operation, but doesn't disclose any behavioral traits like whether it requires authentication, has rate limits, returns structured vs unstructured data, or what happens if the file doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the core purpose. While it could be more specific about what 'comprehensive context' entails, there's no wasted verbiage or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and zero parameters, the description is insufficient. It doesn't explain what format the content returns (text, JSON, etc.), whether it's the entire file or a summary, or how this differs from sibling tools that might provide similar information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't add parameter information beyond what the schema provides, maintaining the baseline score for this situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves content from 'Better Auth LLMs.txt', which provides a specific resource. However, it's vague about what 'comprehensive context' means and doesn't differentiate from sibling tools like 'get_auth_examples' or 'search_better_auth' that might also provide contextual information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, timing considerations, or comparisons to sibling tools like 'get_auth_examples' or 'search_better_auth' that might serve similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all available Better Auth plugins and features organized by category
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter: authentication, databases, integrations, or plugins |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a list organized by category but doesn't mention whether this is a read-only operation, if there are rate limits, authentication requirements, pagination behavior, or what the return format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part of the sentence contributing directly to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and high schema coverage, the description is somewhat complete but lacks critical context. Without annotations or an output schema, it doesn't address behavioral aspects like safety, performance, or return format. The description adequately covers the basic purpose but doesn't compensate for the missing structured data about tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'category' fully documented in the schema including its optional nature, type, description, and enum values. The description adds minimal value beyond the schema by implying category-based organization, but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('Better Auth plugins and features'), and mentions organization by category. However, it doesn't explicitly differentiate from sibling tools like 'search_better_auth' or 'get_feature_details', which could provide similar or overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search_better_auth' and 'get_feature_details' available, there's no indication of when this list-focused tool is preferred over search or detail-oriented tools, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Better Auth documentation by keyword
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find relevant Better Auth features or documentation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic function. It doesn't describe what the search returns (e.g., titles, snippets, full text), whether results are paginated, if there are rate limits, authentication requirements, or how relevance is determined. For a search tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core function without any wasted words. It's appropriately sized for a simple search tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns, how results are structured, or any behavioral aspects like limitations or prerequisites. For a search tool that could return varied documentation content, more context is needed to help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'query' clearly documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target resource ('Better Auth documentation'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_integration_guide' or 'list_better_auth_features', which might also retrieve documentation-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_feature_details' or 'get_integration_guide'. It doesn't specify what type of documentation is searched (e.g., API docs, tutorials, feature descriptions) or when keyword searching is preferable to structured retrieval from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity: list_better_auth_features provides a categorized overview, get_feature_details offers in-depth information on specific items, get_integration_guide focuses on framework/platform integration, get_auth_examples supplies code snippets, get_llms_context delivers comprehensive context via LLMs.txt, and search_better_auth enables keyword-based documentation search. The descriptions clearly differentiate each tool's scope.
All tool names follow a consistent verb_noun pattern with snake_case: get_auth_examples, get_feature_details, get_integration_guide, get_llms_context, list_better_auth_features, and search_better_auth. The naming is predictable and readable throughout, using 'get' for retrieval operations, 'list' for listing, and 'search' for searching, with no deviations in style.
With 6 tools, the count is well-scoped for a documentation and feature exploration server. Each tool earns its place by covering distinct aspects like listing, detailing, integrating, providing examples, offering context, and searching, without being too sparse or bloated. This aligns with typical server scopes of 3-15 tools.
The tool surface is nearly complete for a documentation server, covering core workflows: listing features, getting details, integration guides, examples, context, and search. A minor gap exists in the lack of update or interactive tools (e.g., for modifying or testing configurations), but agents can effectively navigate and retrieve information with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Access Clerk authentication docs, SDK snippets, and quickstart guides
Manage Appwrite projects, databases, auth, storage, functions, and messaging; search Appwrite docs
Backend for vibe coders. Connect Butterbase to any MCP-compatible AI coding tool and provision a full backend automatically — database, authentication, file storage, edge functions, and real-time — from a natural language prompt. No SQL, no configuration, no backend knowledge required. Free to start at butterbase.ai.
Provides access to Avalara developer documentation, integration guides, and code examples
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dabhivijay2478/better-auth-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
