Skip to main content
Glama
purelledhand

MCP Error Relay

by purelledhand

get_error_details

Read-onlyIdempotent

Analyze a specific error message to identify its root cause, receive actionable resolution steps, and detect recurring patterns.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
server_nameYesName of the MCP server where the error occurred
error_messageYesThe error message or pattern to search for
response_formatNoOutput format: 'markdown' for human-readable or 'json' for machine-readablemarkdown
include_stack_traceNoWhether to include full stack traces in the response (default: false)
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds rich behavioral context: it explains the tool performs root-cause analysis, provides pattern warnings, uses 'best-effort analysis even for unknown error patterns', and returns specific error messages like "Error not found". This goes far beyond the annotations.

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 well-structured with bolded section headers, bullet lists, and an example workflow, making it skimmable. It is front-loaded with the core purpose and usage. However, it is quite lengthy and somewhat repetitive: the 'WHEN TO USE' list and 'WORKFLOW' section overlap, and the 'WHAT THIS TOOL DOES' section duplicates content from the opening. Still, the structure prevents it from feeling disorganized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must fully document return values, and it does: it spells out both Markdown and JSON response shapes, including a JSON schema example. It also covers error handling, built-in pattern recognition, and examples for different use cases. This is a model of completeness for a complex analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description repeats parameter names and meanings in the 'Args' section, adding no new detail there, but it enriches understanding with example use cases (e.g., `{ server_name: "slack-mcp-server", error_message: "permission denied" }`) and explains the impact of `response_format` on return structure. This extra context justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'get detailed error analysis' and expands with specific capabilities: 'Identifies ROOT CAUSE (not just symptoms)', 'Provides ACTIONABLE steps to fix the issue', and 'Finds RELATED errors to spot patterns'. It distinguishes itself from sibling get_recent_errors by stating 'Use this AFTER getting recent errors', making the purpose unmistakably distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'WHEN TO USE' section lists four clear scenarios, including 'You got error logs but need to understand WHY it happened' and 'The same error occurred multiple times (pattern analysis)'. The workflow step 'Get recent errors using get_recent_errors' directly names the sibling tool as the preceding step, providing clear context and an implied alternative. No misleading exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/purelledhand/mcp-error-relay'

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