MCP Error Relay
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_recent_errorsA | 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:
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:
WORKFLOW:
Args:
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:
Error Handling:
|
| get_error_detailsA | get detailed error analysis Use this AFTER getting recent errors when you need actionable solutions and root cause analysis. WHEN TO USE:
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:
BUILT-IN ERROR PATTERN RECOGNITION:
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:
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:
Error Handling:
|
| get_server_listA | 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:
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:
USE CASES:
TIP: Look at the "recent_error_count" (last 24h) to identify servers currently having problems! Args:
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:
Error Handling:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: listing servers, fetching recent errors, and analyzing a specific error. There is no overlap; the tools are complementary stages of a single diagnostic workflow.
All tool names follow the same 'get_' + noun pattern in snake_case (get_recent_errors, get_error_details, get_server_list). The naming is perfectly consistent and predictable.
Three tools is well-scoped for an error relay server. Each tool earns its place, covering discovery, retrieval, and analysis without any redundancy.
The tool set covers the full error-diagnosis workflow: discover available servers, retrieve error logs, and get root-cause analysis with actionable fixes. There are no obvious gaps or dead ends.