Better Auth MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as analyze_current_auth for detection, setup_better_auth for installation, and test_security for security testing. However, analyze_logs and monitor_auth_flows could be slightly confused as both involve monitoring aspects, though analyze_logs focuses on historical logs while monitor_auth_flows is real-time. Overall, the descriptions help clarify boundaries, but there is minor overlap in monitoring-related tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as analyze_current_auth, generate_migration_plan, and test_auth_flows. The verbs (analyze, generate, monitor, setup, test) are clear and predictable, making the naming highly consistent and readable throughout the set.
Tool Count5/5
With 8 tools, the count is well-scoped for a server focused on Better-Auth migration and management. Each tool earns its place by covering distinct aspects like analysis, setup, testing, and monitoring, providing a comprehensive yet manageable surface without being overly sparse or bloated.
Completeness4/5
The tool set covers key areas for Better-Auth migration, including analysis, setup, testing, and monitoring, with no major gaps in the core workflow. However, there might be minor gaps, such as tools for updating or customizing Better-Auth configurations post-setup, but agents can likely work around these with existing tools like setup_better_auth and test_auth_flows.
Average 2.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 mentions analyzing logs for issues but does not specify whether this is a read-only operation, what permissions are required, how results are returned, or any rate limits. This is a significant gap for a tool that likely involves data processing without structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function. It is front-loaded and wastes no words, though it could benefit from more detail to improve utility. The brevity is appropriate but borders on under-specification given the lack of additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of log analysis and the absence of annotations and output schema, the description is incomplete. It does not explain what 'analyze' entails, what issues it detects, or the format of results. With no structured fields to compensate, the description fails to provide sufficient context for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'timeRange' documented as 'Time range to analyze (e.g., '24h', '7d')'. The description does not add any meaning beyond this, such as default values or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as analyzing Better-Auth logs for issues, which is clear but vague. It specifies the resource (Better-Auth logs) and general action (analyze for issues), but lacks specificity on what 'analyze' entails or what types of issues it detects. It does not distinguish from siblings like 'analyze_current_auth' or 'monitor_auth_flows', which might have overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings such as 'analyze_current_auth', 'monitor_auth_flows', and 'test_security', there is no indication of context, prerequisites, or exclusions. This leaves the agent without direction on selecting the appropriate tool for log analysis tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'real-time monitoring' but does not explain what this entails—e.g., whether it streams data, requires specific permissions, has side effects, or how results are returned. This leaves critical behavioral traits unspecified for a monitoring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose, though it could be more structured by including key details. It earns a high score for brevity but loses a point for under-specification relative to the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a monitoring tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, output format, error handling, or integration with sibling tools. This makes it inadequate for an agent to understand the full context of use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'duration' parameter fully documented. The description does not add any meaning beyond the schema, as it does not mention parameters at all. Baseline score is 3 since the schema adequately covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Real-time monitoring of authentication processes' states a general purpose but lacks specificity about what 'monitoring' entails (e.g., observing, logging, alerting) and does not distinguish it from sibling tools like 'analyze_current_auth' or 'test_auth_flows'. It uses a verb ('monitoring') but is vague about the resource scope and operational details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'analyze_current_auth' for static analysis or 'test_auth_flows' for testing. The description implies a real-time context but does not specify prerequisites, exclusions, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Test authentication workflows' but doesn't explain what the tool does (e.g., simulates flows, validates configurations, returns results), potential side effects (e.g., non-destructive testing), or any constraints like rate limits. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core purpose without any wasted text. It's appropriately sized for a simple tool, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'testing' involves, what results to expect, or how it differs from siblings, leaving the agent with insufficient context to use the tool effectively. This is a notable shortfall for a tool with one parameter but critical behavioral unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'flows' parameter clearly documented as 'Authentication flows to test' and an enum of options. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Test authentication workflows' states the general purpose (testing) and domain (authentication workflows), but it's vague about what 'test' entails (e.g., validation, simulation, performance) and doesn't differentiate from siblings like 'monitor_auth_flows' or 'test_security'. It avoids tautology by not just restating the name, but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, context (e.g., during development or debugging), or exclusions, leaving the agent to infer usage from the name alone. This is a significant gap given siblings like 'monitor_auth_flows' and 'test_security' that might overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Run security tests' but doesn't specify what this entails—whether it's a read-only diagnostic, a destructive test, requires specific permissions, has side effects, or details about output format. This leaves significant gaps for a security testing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core action. It's appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of security testing, no annotations, no output schema, and low schema coverage, the description is inadequate. It lacks details on behavior, parameters, and expected results, making it incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'tests' parameter beyond what's implied by the tool name. It doesn't explain the enum values ('password-policy', 'rate-limiting', 'session-management') or their meanings, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run') and resource ('security tests') with specific context ('on Better-Auth setup'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'test_auth_flows' or 'analyze_current_auth', which might cover overlapping security aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'test_auth_flows' or 'analyze_current_auth'. The description lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool detects and analyzes, but doesn't disclose behavioral traits like what 'analyze' entails (e.g., output format, depth of analysis, whether it modifies files, or if it requires specific permissions). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 is appropriately sized and front-loaded, with every part earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what the analysis returns, how results are presented, or any behavioral context needed for effective use. For a tool with 'analyze' in its name, this lack of output information is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'projectPath' well-documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides, such as format expectations or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Detect and analyze existing auth.js/next-auth implementation.' It specifies the action (detect and analyze) and the target resource (auth.js/next-auth implementation). However, it doesn't explicitly differentiate from siblings like 'analyze_project' or 'setup_better_auth' which might have overlapping scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, appropriate contexts, or exclusions. With siblings like 'analyze_project' (broader analysis) and 'setup_better_auth' (implementation-focused), the lack of differentiation leaves usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 analyzes and recommends, but doesn't disclose critical traits: whether it's read-only or mutating, what permissions are needed, if it has side effects, rate limits, or what the output looks like. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 unnecessary words. It directly states what the tool does, making it appropriately sized and structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analysis and recommendation tool), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis entails, what the recommendation output includes, or behavioral aspects like safety or performance. With no structured fields to compensate, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'projectPath' clearly documented as 'Path to the project root.' The description adds no additional parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze project structure and dependencies to recommend Better-Auth setup approach.' It specifies the verb ('analyze'), resource ('project structure and dependencies'), and outcome ('recommend Better-Auth setup approach'). However, it doesn't explicitly differentiate from siblings like 'analyze_current_auth' or 'setup_better_auth', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like 'analyze_current_auth', 'setup_better_auth', and 'generate_migration_plan', there's no indication of context, prerequisites, or exclusions. The description implies usage for analysis but lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a plan, implying a read-only or advisory operation, but doesn't clarify if it modifies files, requires specific permissions, has side effects, or details output format (e.g., markdown, JSON). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create step-by-step migration plan') and specifies the context ('from existing auth to Better-Auth'). There is zero waste or redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of migration planning, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects (e.g., whether it generates code snippets or just documentation), output details, or integration with sibling tools. This leaves gaps for an AI agent to understand the tool's full context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema ('projectPath' and 'currentAuthType' with enum values). The description adds no additional parameter semantics beyond what the schema provides, such as format examples for 'projectPath' or implications of 'currentAuthType' choices. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('step-by-step migration plan') with the specific context ('from existing auth to Better-Auth'). It distinguishes from siblings like 'analyze_current_auth' or 'setup_better_auth' by focusing on planning rather than analysis or implementation. However, it doesn't explicitly differentiate from all siblings (e.g., 'monitor_auth_flows' or 'test_auth_flows'), keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., should 'analyze_current_auth' be run first?), exclusions (e.g., not for non-migration scenarios), or comparisons to siblings like 'setup_better_auth' (which might handle implementation). This lack of contextual usage information limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Install and configure,' implying a mutation operation, but fails to detail critical aspects like required permissions, whether it modifies existing files, potential side effects, or error handling. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a setup/configuration tool with no annotations and no output schema, the description is insufficient. It lacks details on what 'Install and configure' entails operationally, expected outcomes, error scenarios, or how it interacts with sibling tools, making it incomplete for informed agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the two parameters ('projectPath' and 'config') and their nested properties. The description does not add any extra meaning beyond the schema, such as explaining the purpose of 'config' options or providing examples, so it meets the baseline for adequate but unenriched parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install and configure') and the target resource ('Better-Auth in the project'), making the purpose understandable. However, it does not explicitly differentiate this tool from siblings like 'analyze_current_auth' or 'generate_migration_plan', which might involve related but distinct operations, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as whether it's for initial setup versus updates, or how it relates to sibling tools like 'analyze_current_auth' or 'test_auth_flows'. It lacks context on prerequisites or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![better-auth-mcp-server MCP server](https://glama.ai/mcp/servers/LexiconAlex/better-auth-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/LexiconAlex/better-auth-mcp-server)

Score Badge

Copy to your README.md:

[![better-auth-mcp-server MCP server](https://glama.ai/mcp/servers/LexiconAlex/better-auth-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/LexiconAlex/better-auth-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LexiconAlex/better-auth-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server