Feature: Add UnauthenticatedMethods option to RequireBearerTokenOptions

[mbrahmbhatt]

Is your feature request related to a problem? Please describe.

Summary

Add an UnauthenticatedMethods option to RequireBearerTokenOptions to allow specific MCP methods (like initialize and tools/list) to bypass authentication.

Motivation

Gateway proxies like LiteLLM need to call certain MCP methods without authentication to perform capability discovery before establishing authenticated sessions. The MCP protocol's initialize handshake and tools/list capability discovery are foundational operations that may need to occur before authentication context is available.

Currently, the RequireBearerToken middleware applies authentication uniformly to all requests, requiring workarounds like custom middleware that parses the JSON-RPC body to check the method name before applying auth:

// Current workaround - parses body twice, feels hacky
func WithUnauthenticatedMethods(authMiddleware func(http.Handler) http.Handler, methods []string) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
authenticated := authMiddleware(next)
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
body, _ := io.ReadAll(r.Body)
r.Body = io.NopCloser(bytes.NewReader(body))

        var req struct{ Method string `json:"method"` }
        if json.Unmarshal(body, &req) == nil && slices.Contains(methods, req.Method) {
            next.ServeHTTP(w, r)
            return
        }
        authenticated.ServeHTTP(w, r)
    })
}

}

Describe the solution you'd like
Proposed Solution

Add an UnauthenticatedMethods field to RequireBearerTokenOptions:

type RequireBearerTokenOptions struct {
ResourceMetadataURL string
Scopes []string
// UnauthenticatedMethods lists MCP method names that should bypass authentication.
// Common values: "initialize", "tools/list", "resources/list", "prompts/list"
UnauthenticatedMethods []string
}

The middleware would then check the JSON-RPC method name and skip authentication for whitelisted methods.

Use Cases

1. Gateway Proxies: LiteLLM and similar gateways need to discover server capabilities before routing authenticated requests
2. Capability Discovery: Clients may need to list available tools/resources before deciding which scopes to request during OAuth
3. Health Checks: Some deployments may want ping or similar methods to be unauthenticated for monitoring

Describe alternatives you've considered

1. MCP-level middleware: Apply auth at the mcp.Middleware level instead of HTTP, but this loses proper HTTP 401/WWW-Authenticate responses needed for OAuth flows
2. Separate endpoints: Serve authenticated and unauthenticated methods on different paths, but this complicates client configuration

Additional context
The TypeScript SDK's examples show similar patterns where auth is applied selectively. Having first-class support in the Go SDK would improve the developer experience for production deployments.

[maciej-kisiel]

Hi @mbrahmbhatt, thanks for filing the enhancement proposal. Is this requirement of LiteLLM documented somewhere?