get detailed error analysis

Use this AFTER getting recent errors when you need actionable solutions and root cause analysis.

WHEN TO USE:

• You got error logs but need to understand WHY it happened

• You need specific steps to fix the problem

• The same error occurred multiple times (pattern analysis)

• You need stack traces for deeper debugging

WHAT THIS TOOL DOES: ✅ Identifies ROOT CAUSE (not just symptoms) ✅ Provides ACTIONABLE steps to fix the issue ✅ Finds RELATED errors to spot patterns ✅ Analyzes if error is recurring (warns against pointless retries)

WORKFLOW:

1. Get recent errors using get_recent_errors

2. Copy the error message you want to analyze

3. Call THIS tool with that error message

4. Get: Root cause + Specific fix actions + Pattern warnings

BUILT-IN ERROR PATTERN RECOGNITION:

• Permission/Auth errors -> Suggests checking credentials, scopes, permissions

• Rate limit errors -> Suggests backoff strategies, caching, tier upgrades

• Timeout errors -> Suggests increasing timeout, chunking requests

• Not found errors -> Suggests verifying IDs, checking deletions

• Network errors -> Suggests connectivity checks, firewall settings

• Invalid input errors -> Suggests validation, format checking

• Server errors (5xx) -> Identifies as provider-side, suggests waiting

EXAMPLE USE CASE: Error: "Failed to send message" → Get recent errors: shows "missing_scope: chat:write" → Analyze error: ROOT CAUSE = "Permission error" ACTIONS = ["Add chat:write OAuth scope", "Regenerate token"] → Fix immediately instead of retrying 4+ times!

Args:

• server_name (string): Name of the MCP server where error occurred

• error_message (string): The error message or pattern to search for

• include_stack_trace (boolean): Include full stack traces (default: false)

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For Markdown format: Human-readable analysis with root cause and action steps For JSON format: Structured data with schema: { "root_cause": string, // Identified root cause of the error "error": { // The original error details "timestamp": string, "server_name": string, "tool_name": string, "message": string, "stack_trace": string // Only if include_stack_trace is true }, "suggested_actions": string[], // List of actionable steps to resolve "related_errors": [ // Similar errors for pattern analysis { "timestamp": string, "message": string } ] }

Examples:

• Permission error -> { server_name: "slack-mcp-server", error_message: "permission denied" }

• Rate limit debugging -> { server_name: "github_mcp", error_message: "rate limit", include_stack_trace: true }

• Recurring error -> { server_name: "jira-mcp-server", error_message: "timeout" }

Error Handling:

• Returns error if server_name not found

• Returns "Error not found" if no matching error in logs

• Provides best-effort analysis even for unknown error patterns

Get Recent MCP Server Errors

⚠️ CALL THIS IMMEDIATELY when ANY MCP tool fails with vague/unclear error messages!

TRIGGER CONDITIONS - Call this tool when you see:

• "Error:", "Failed:", "Exception:", "Error occurred"

• "Permission denied", "Unauthorized", "Forbidden", "Access denied"

• "Rate limit", "Too many requests", "429"

• "Timeout", "Timed out", "Connection refused"

• "Not found", "404", "Invalid", "Malformed"

• "Network error", "ECONNREFUSED", "ETIMEDOUT"

• ANY vague error that doesn't explain the root cause

• BEFORE attempting to retry any failed operation

WHY USE THIS: ❌ Without logs: Blind retry -> fail -> retry -> fail -> retry (wastes 50-200+ tokens) ✅ With logs: Check logs once (10 tokens) -> see real error -> fix immediately

TOKEN ECONOMICS:

• Cost of checking logs: ~10-20 tokens

• Cost of 3-4 blind retries: 50-200 tokens

• ROI: 5-20x token savings per error

WORKFLOW:

1. MCP tool fails with unclear error

2. IMMEDIATELY call this tool with server_name

3. Read the detailed error logs

4. Identify root cause (permissions? rate limit? invalid input?)

5. Take correct action (don't retry blindly!)

Args:

• server_name (string): Name of the MCP server (e.g., 'slack-mcp-server', 'github_mcp')

• limit (number): Maximum number of errors to return, 1-100 (default: 10)

• tool_name (string, optional): Filter by specific tool name

• hours (number, optional): Only show errors from last N hours, 1-168

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For Markdown format: Human-readable error log with timestamps and messages For JSON format: Structured data with schema: { "total": number, // Number of errors found "errors": [ { "timestamp": string, // ISO 8601 timestamp "level": string, // Log level (ERROR) "server_name": string, // MCP server name "tool_name": string, // Tool that caused the error (optional) "message": string, // Error message "error_code": string, // Error code if available (optional) "stack_trace": string, // Stack trace if available (optional) "request_id": string // Request ID for tracing (optional) } ] }

Examples:

• Slack tool failed -> IMMEDIATELY: { server_name: "slack-mcp-server", limit: 5 }

• GitHub API error -> BEFORE RETRY: { server_name: "github_mcp", hours: 1 }

• Repeated failures -> { server_name: "jira-mcp-server", tool_name: "create_issue" }

Error Handling:

• Returns error if server_name not found. Use list_servers to see available servers.

• Returns "No errors found" if the log database has no error entries matching the criteria.

List Available MCP Servers

Use this tool FIRST if you don't know which MCP server name to use for error checking.

WHEN TO USE:

• A tool failed but you don't know the exact server_name

• You want to see which servers have recent errors

• You're not sure if logs exist for a particular server

• You need to identify which servers are most problematic

WHAT THIS TOOL SHOWS: ✅ All available MCP server names (needed for other tools) ✅ Total error counts per server ✅ Recent errors in last 24 hours ✅ When logs were last updated ✅ Full log file paths

WORKFLOW:

1. Tool fails, but you're unsure of the server_name

2. Call THIS tool to list all available servers

3. Find the server with recent errors or matching your failed tool

4. Use that server_name to call get_recent_errors

USE CASES:

• Error says "slack tool failed" -> List servers -> Find "slack-mcp-server" -> Check its logs

• Multiple tools failing -> List servers -> See which has most errors (24h column) -> Investigate that one first

• New to the system -> List servers -> Understand available MCP infrastructure

TIP: Look at the "recent_error_count" (last 24h) to identify servers currently having problems!

Args:

• include_stats (boolean): Include error statistics for each server (default: true)

• response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For Markdown format: Human-readable list with server names and stats For JSON format: Structured data with schema: { "total": number, // Number of servers found "servers": [ { "server_name": string, // Name of the MCP server "log_file_path": string, // Full path to log file "last_modified": string, // ISO 8601 timestamp of last update "total_errors": number, // Total error count (if include_stats=true) "recent_error_count": number // Errors in last 24h (if include_stats=true) } ] }

Examples:

• Don't know server name -> {}

• Quick server list -> { include_stats: false }

• Find problematic server -> {} (then check recent_error_count)

Error Handling:

• Returns empty list if no log files found in configured directory

• Gracefully handles log files with different formats