MCP Server for Thunder

[sahandilshan]

It would be great we add a mcp server for thunder. The MCP server should be able to do below things mainly

• Execute Thunder operations (EX: CRUD operations on Application, IDP, Users)
• Guide developers on how to integrate their applications with Thunder

[darshanasbg]

+1 Lets go ahead with a feature proposal..

@shashimalcse @thiva-k also interested on this.

[shashimalcse]

i was thinking exposing /mcp endpoint from thunder and write separate handlers to handle mcp tools something similar to rest handlers.

[sahandilshan]

This depends on how we are going to provide this feature. I'm assuming that packing the /mcp server with the thunder is not suitable at the moment. Let's get it out from the thunder runtime. We can decide this on feature request

[darshanasbg]

@sahandilshan sorry for jumping on this late.. Thunder needs to have native support for AI integrations,, So we should have the MCP in the default runtime.. rather as an addon.. Any issue on doing that?

[sahandilshan]

Hi @darshanasbg
No issue with that. Actually that is the correct approach. My initial idea is not valid

[darshanasbg]

Ack. Just after posing above reply, I saw your comment on the below thread which indicates your alignment on the inbuilt MCP.

[thiva-k]

Based on the recent improvements, one of the following approaches can be considered for the MCP server implementation:

Directory Structure

backend/internal/mcp/
├── handler.go
├── init.go
└── tools/
    ├── registry.go
    ├── application_tools.go
    ├── user_tools.go
    ├── group_tools.go
    └── role_tools.go

1. Route Registration:

// init.go - MCP service initialization
func Initialize(mux *http.ServeMux, ...) {
    handler := newMCPHandler(...) // Create handler with dependencies
    mux.HandleFunc("POST /mcp", handler.HandleMCPRequest)
}

2. JSON-RPC Method Dispatch:

// handler.go - Main MCP handler receives all requests
func (h *mcpHandler) HandleMCPRequest(w http.ResponseWriter, r *http.Request) {
    
    var req JSONRPCRequest
    json.NewDecoder(r.Body).Decode(&req)
    
    // Dispatch based on JSON-RPC method
    switch req.Method {
    case "tools/list":
        h.handleToolsList(w, r, req)
    case "tools/call":
        h.handleToolCall(w, r, req) // Routes to specific tool
    case "resources/list":
        h.handleResourcesList(w, r, req)
    // ... other MCP methods
    }
}

3. Tool Resolution:

// handler.go - MCP handler with dependencies (type varies by approach)
type mcpHandler struct {
    registry    *ToolRegistry
    dependencies interface{} // Approach-specific: services, handlers, or HTTP client
}

// Tool call handler
func (h *mcpHandler) handleToolCall(w http.ResponseWriter, r *http.Request, req JSONRPCRequest) {
    
    toolName := req.Params.Name // e.g., "create_application"
    
    // Look up tool in registry
    tool := h.registry.GetTool(toolName)
    if tool == nil {
        // Return JSON-RPC error: tool not found
        return
    }
    
    // Execute tool with context, arguments, and dependencies
    // Dependencies type varies by approach
    response, err := tool.Execute(ctx, req.Params.Arguments, h.dependencies)
    // ... return JSON-RPC response
}

4. Tool Registry & Execution:

// tools/registry.go - Generic tool executor interface
type ToolExecutor interface {
    Execute(ctx context.Context, args map[string]interface{}, deps interface{}) (*ToolCallResponse, error)
}

type ToolRegistry struct {
    tools map[string]ToolExecutor
}

func (r *ToolRegistry) RegisterTool(name string, executor ToolExecutor) {
    r.tools[name] = executor
}

func (r *ToolRegistry) GetTool(name string) ToolExecutor {
    return r.tools[name]
}

// Tool adapters wrap tool functions to implement ToolExecutor
// Each approach defines adapters that extract the right dependencies

There are three feasible approaches on how we are going to provide the actual tool functionality/implementation:

Approach 1: Direct Service Layer Calls

MCP tools call Thunder's service layer interfaces directly.

Example:

// tools/application_tools.go
// Tool function receives only the dependency it needs (appService)
func createApplication(ctx context.Context, args map[string]interface{}, appService ApplicationServiceInterface) (*ToolCallResponse, error) {
  
    appDTO := &model.ApplicationDTO{
        Name: args["name"].(string),
        // ... other fields
    }
    
    createdApp, svcErr := appService.CreateApplication(appDTO)
    if svcErr != nil {
        return nil, svcErr
    }
    
    return &ToolCallResponse{
        Content: []ToolCallContent{
            {Type: "text", Text: fmt.Sprintf("Created application: %s", createdApp.ID)},
        },
    }, nil
}

Pros:

• Direct service access with type safety
• No HTTP overhead
• Fastest performance

Cons:

• Tightly coupled to service layer
• Requires duplicating logic for REST and MCP handlers
• Can't extract to separate runtime
• Service interface changes might break MCP

Approach 2: Wrap Existing HTTP Handlers

MCP tools call Thunder's existing HTTP handlers, reusing all the handler logic.

Example:

// tools/application_tools.go
func createApplication(ctx context.Context, args map[string]interface{}, appHandler *applicationHandler) (*ToolCallResponse, error) {
    // Build HTTP request
    body := map[string]interface{}{"name": args["name"]}
    reqBody, _ := json.Marshal(body)
    req := httptest.NewRequest("POST", "/api/v1/applications", bytes.NewReader(reqBody))
    req.Header.Set("Content-Type", "application/json")
    
    // Copy auth context from MCP request context to request if needed

    // Invoke existing handler
    w := httptest.NewRecorder()
    appHandler.HandleApplicationPostRequest(w, req)
    
    // Parse response
    var response model.ApplicationDTO
    json.Unmarshal(w.Body.Bytes(), &response)
    
    return &ToolCallResponse{
        Content: []ToolCallContent{
            {Type: "text", Text: fmt.Sprintf("Created application: %s", response.ID)},
        },
    }, nil
}

Pros:

• No code duplication - reuses all handler logic
• Automatically gets handler improvements
• REST API and MCP behave identically
• Easy to maintain

Cons:

• Usage of httptest or creating HTTP requests
• Can't extract to separate runtime
• Some HTTP overhead

Approach 3: REST API Wrapper

MCP tools make HTTP calls to Thunder's REST APIs, treating it like an external service. External tools also can be used for this transformation if needed.

Example:

// tools/application_tools.go
func createApplication(ctx context.Context, args map[string]interface{}, client *http.Client) (*ToolCallResponse, error) {
    body := map[string]interface{}{"name": args["name"]}
    reqBody, _ := json.Marshal(body)
    
    // Validate and handle token
    
    req, _ := http.NewRequest("POST", "https://localhost:8090/api/v1/applications", bytes.NewReader(reqBody))
    req.Header.Set("Authorization", "Bearer "+token)
    req.Header.Set("Content-Type", "application/json")
    
    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    
    var response model.ApplicationDTO
    json.NewDecoder(resp.Body).Decode(&response)
    
    return &ToolCallResponse{
        Content: []ToolCallContent{
            {Type: "text", Text: fmt.Sprintf("Created application: %s", response.ID)},
        },
    }, nil
}

Pros:

• Clean separation
• Can extract to separate runtime/proxy
• Works over network
• Independent deployment

Cons:

• HTTP serialization overhead
• Network latency per call
• Need to handle HTTP errors/retries

Thunder's security middleware already handles auth, so MCP endpoints get secured automatically and this can be also improved to handle MCP specific validations better.

Thunder can already act as the OAuth 2.0 authorization server for MCP clients (https://github.com/asgardeo/thunder/blob/main/docs/guides/standards-based/oauth2-oidc/features/mcp-server-securing.md). Clients register via /oauth2/dcr/register, get tokens from /oauth2/token, and validate using /oauth2/jwks. The MCP server just needs to expose /.well-known/oauth-protected-resource with Thunder's authorization server info.

Given Thunder's architecture and the discussion to expose MCP server functionalities only for lower environments, please let know which approach aligns best with the requirements?

[darshanasbg]

I think we should go with Approach 1.

If we consider the cons mentioned in the "Approach 1:, refer following comments,

Tightly coupled to service layer

Coupling to some layer is inevitable, unless we duplicate the logic which is also not an option.

Requires duplicating logic for REST and MCP handlers

If there's any duplicated logic, that is a indication, this logic is not suitable for handler\protocol level, rather should be in the service layer. So let's evaluate these logics case by case and move to service layer if needed.. Note, in handler level, its ok to have the logic related to data conversion of transport level data model to service level data model and vise versa.

Can't extract to separate runtime

Why this is a problem if we provide a inbuilt one. Secondarily, if someone need external MCP, this approach not block anything, they can build using our rest APIs. Only the downside is the code duplication with the inbuilt MCP.

Service interface changes might break MCP

Fundamentally this is same as the first point.

So, I don't think the cons shared in Approach 1 has a merit thus lets go ahead with the Approach 1.

[sahandilshan]

Hi @thiva-k,

I also agree with @darshanasbg

Can extract to separate runtime/proxy

Had a discussion about this with @shashimalcse back then. This is kind of an anti pattern of MCP spec where we provide an proxy to access the actual resource server.

Requires duplicating logic for REST and MCP handlers

Also agreeing with @darshanasbg here. This is not a blocker, if duplicate code there, then we can extract it to a common place and reuse.

My suggestion is that the any service that we should expose from API should be available with MCP as well (May not be 100% valid when advance use case comes) and both API (REST) and MCP should call the same service method.

[shashimalcse]

Hi @thiva-k

I also think we should go with Approach 1.

When designing MCP servers, matching tools directly to REST APIs is an anti-pattern, so keep that in mind when designing the tools.

We also need to think about scope validation for tools as well. This will be handled differently from REST APIs.

[thiva-k]

We may not need a separate runtime as of now, since we have clear and reusable service/handler layer separation in Thunder. Also it would be better in terms of UX and deployment perspective to have a single runtime. We could also provide a config to enable the MCP server only if needed within this runtime.

Approach 1 may require duplication of some pre/post-processing logic that are present in HTTP handlers (e.g. pagination, DTO conversions, sanitizing, secret masking, etc.).

Approach 2 reduces this redundancy since we can pass-through the MCP tool args as an HTTP req object to the existing HTTP handler and let it handle it, reusing the existing logic. But may have the overhead of HTTP object conversions and is a less cleaner approach.