Server has 8 tools with schemas and descriptions present, but quality is significantly below production baseline. Most tool descriptions are generic and under 100 chars (well below the 194-char average for A+ tools). Parameter descriptions are sparse or missing entirely. No output schemas documented. Error handling is minimal, tool implementations are stubs that return placeholder text. No tool annotations (readOnlyHint/destructiveHint). The setup_better_auth tool exposes API credentials as parameters, violating secret-injection pattern. Tools like analyze_project, analyze_logs, and monitor_auth_flows lack actionable parameter guidance (e.g., what constitutes a valid timeRange format). No pagination support documented. Naming is reasonable (verb_noun style) but descriptions fail to explain WHEN to use each tool or what it returns.

• Move projectId and apiKey from setup_better_auth parameters to environment variables (BETTER_AUTH_PROJECT_ID, BETTER_AUTH_API_KEY). Read them server-side and remove from tool schema.
• Document output schemas for all tools. E.g., analyze_project should return {framework: string, dependencies: string[], recommendedSetup: string}. Include these in tool definitions so LLMs know what to expect.
• Expand parameter descriptions with format constraints. E.g., timeRange: 'Time range to analyze (e.g., "24h", "7d", "30d"). Must be a number followed by h/d/w suffix.' Use enums or regex patterns where applicable.
• Add tool annotations: mark setup_better_auth with destructiveHint=true; mark all read-only tools with readOnlyHint=true. This guides agent retry logic and safety policies.
• Clarify tool selection criteria in descriptions. E.g., analyze_project: 'Call this FIRST to understand the project structure before recommending a setup approach. Returns framework type, dependencies, and recommended Better-Auth configuration.' This prevents agent confusion between similar tools.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry