You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
This document describes the error handling patterns used in the GitHub MCP Server, specifically how we handle GitHub API errors and avoid direct use of mcp-go error types.
4
+
5
+
##Overview
6
+
7
+
The GitHub MCP Server implements a custom error handling approach that serves two primary purposes:
2.**Middleware Inspection**: Store detailed error information in the request context for middleware analysis
11
+
12
+
This dual approach enables better observability and debugging capabilities, particularly for remote server deployments where understanding the nature of failures (rate limiting, authentication, 404s, 500s, etc.) is crucial for validation and monitoring.
13
+
14
+
##Error Types
15
+
16
+
###GitHubAPIError
17
+
18
+
Used for REST API errors from the GitHub API:
19
+
20
+
```go
21
+
typeGitHubAPIErrorstruct {
22
+
Messagestring`json:"message"`
23
+
Response *github.Response`json:"-"`
24
+
Errerror`json:"-"`
25
+
}
26
+
```
27
+
28
+
###GitHubGraphQLError
29
+
30
+
Used for GraphQL API errors from the GitHub API:
31
+
32
+
```go
33
+
typeGitHubGraphQLErrorstruct {
34
+
Messagestring`json:"message"`
35
+
Errerror`json:"-"`
36
+
}
37
+
```
38
+
39
+
##Usage Patterns
40
+
41
+
###For GitHub REST API Errors
42
+
43
+
Instead of directly returning`mcp.NewToolResultError()`, use:
-**User-actionable errors** (authentication failures, rate limits, 404s) should be returned as failed tool calls using the error response functions
78
+
-**Developer errors** (JSON marshaling failures, internal logic errors) should be returned as actual Go errors that bubble up through the MCP framework
79
+
80
+
###Context Limitations
81
+
82
+
This approach was designed to work around current limitations in mcp-go where context is not propagated through each step of request processing. By storing errors in context values, middleware can inspect them without requiring context propagation.
83
+
84
+
###Graceful Error Handling
85
+
86
+
Error storage operations in context are designed to fail gracefully - if context storage fails, the tool will still return an appropriate error response to the client.
87
+
88
+
##Benefits
89
+
90
+
1.**Observability**: Middleware can inspect the specific types of GitHub API errors occurring
91
+
2.**Debugging**: Detailed error information is preserved without exposing potentially sensitive data in logs
92
+
3.**Validation**: Remote servers can use error types and HTTP status codes to validate that changes don't break functionality
93
+
4.**Privacy**: Error inspection can be done programmatically using`errors.Is` checks without logging PII
This approach ensures that both the client receives an appropriate error response and any middleware can inspect the underlying GitHub API error for monitoring and debugging purposes.