feat: add resource handler middleware capability

[tjhop]

This is a fairly direct adaption of the existing tool handler middleware
to also allow support for resource middlewares.

Use case: I'm working on an MCP server that manages an API client that
is used for both tool and resource calls. The tool handler middleware
provides a nice pattern to wrap tool calls that fits some use cases
better than the before/after tool call hooks. It would be helpful to
have first party support for this pattern in the library so I don't need
to work around it with custom closures etc.

Notes:

• There are currently no tests (that I can find) that exercise the existing tool
  handler middleware logic, so I did not add tests for the resource
  handler middleware logic.
• Existing docs, specifically those for the streamable HTTP transport,
  reference some middleware functions (for both tools and resources)
  that don't exist (ex: s.AddToolMiddleware does not,
  s.AddResourceMiddleware does not exist, etc). It seems they may be out
  of date. Happy to discuss updates to docs in a separate PR.

[coderabbitai]

Walkthrough

Introduces resource-specific middleware in server/server.go, adding ResourceHandlerMiddleware, storage on MCPServer, WithResourceHandlerMiddleware and WithResourceRecovery options, initialization wiring, and wrapping of direct resource handlers with a middleware chain (reverse order) under lock. Recovery middleware converts panics to typed errors containing the resource URI.

Changes

Cohort / File(s)	Change Summary
Resource middleware integration server/server.go	Added ResourceHandlerMiddleware type and storage on MCPServer; introduced WithResourceHandlerMiddleware and WithResourceRecovery ServerOptions; initialized middleware storage; updated resource read path to wrap direct handlers with middleware chain (reverse order) under lock; recovery wrapper converts panics to typed errors with resource URI; minor naming/placement adjustments.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Tip

🔌 Remote MCP (Model Context Protocol) integration is now available!

Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats.

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbit in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbit in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbit gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbit read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbit help to get the list of available commands.

Other keywords and placeholders

• Add @coderabbit ignore or @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbit summary or @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbit or @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

server/server.go (1)

872-887: Recovery/middleware not applied to template-based resource handlers.
Direct handlers are wrapped; template handlers are not. Panics in template handlers will bypass WithResourceRecovery and can crash the server. Align behavior by wrapping template handlers with the same chain (use an adapter because function types differ).

Apply this diff:

@@
   s.resourcesMu.RUnlock()
 
-  if matched {
-    contents, err := matchedHandler(ctx, request)
+  if matched {
+    // Adapt and wrap template handler with resource middlewares
+    finalTemplateHandler := matchedHandler
+    s.middlewareMu.RLock()
+    mw := s.resourceHandlerMiddlewares
+    for i := len(mw) - 1; i >= 0; i-- {
+      next := finalTemplateHandler
+      wrapped := mw[i](func(ctx context.Context, req mcp.ReadResourceRequest) ([]mcp.ResourceContents, error) {
+        return next(ctx, req)
+      })
+      finalTemplateHandler = func(ctx context.Context, req mcp.ReadResourceRequest) ([]mcp.ResourceContents, error) {
+        return wrapped(ctx, req)
+      }
+    }
+    s.middlewareMu.RUnlock()
+
+    contents, err := finalTemplateHandler(ctx, request)
     if err != nil {
       return nil, &requestError{
         id:   id,
         code: mcp.INTERNAL_ERROR,
         err:  err,
       }
     }
     return &mcp.ReadResourceResult{Contents: contents}, nil
   }

Also applies to: 917-926

🧹 Nitpick comments (2)

server/server.go (2)

230-241: Guard against nil middlewares and document ordering.
A nil middleware would panic when invoked. Also, note reverse-application in the doc for clarity.

Apply this diff:

 // WithResourceHandlerMiddleware allows adding a middleware for the
 // resource handler call chain.
 func WithResourceHandlerMiddleware(
   resourceHandlerMiddleware ResourceHandlerMiddleware,
 ) ServerOption {
   return func(s *MCPServer) {
-    s.middlewareMu.Lock()
-    s.resourceHandlerMiddlewares = append(s.resourceHandlerMiddlewares, resourceHandlerMiddleware)
-    s.middlewareMu.Unlock()
+    if resourceHandlerMiddleware == nil {
+      return // ignore nil middleware to avoid panics
+    }
+    s.middlewareMu.Lock()
+    // Note: middlewares run in reverse registration order (last added runs first).
+    s.resourceHandlerMiddlewares = append(s.resourceHandlerMiddlewares, resourceHandlerMiddleware)
+    s.middlewareMu.Unlock()
   }
 }

---

242-259: Include stack traces in recovery for better diagnostics.
Parity with tool recovery is fine, but a stack greatly accelerates incident triage.

Apply this diff:

 func WithResourceRecovery() ServerOption {
   return WithResourceHandlerMiddleware(func(next ResourceHandlerFunc) ResourceHandlerFunc {
     return func(ctx context.Context, request mcp.ReadResourceRequest) (result []mcp.ResourceContents, err error) {
       defer func() {
         if r := recover(); r != nil {
-          err = fmt.Errorf(
-            "panic recovered in %s resource handler: %v",
-            request.Params.URI,
-            r,
-          )
+          stack := debug.Stack()
+          err = fmt.Errorf("panic recovered in %s resource handler: %v\n%s", request.Params.URI, r, stack)
         }
       }()
       return next(ctx, request)
     }
   })
 }

Add the import:

// at top of file
import "runtime/debug"

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 4e353ac and 4654e51.

📒 Files selected for processing (1)

• server/server.go (5 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-06-23T11:10:42.948Z

Learnt from: floatingIce91
PR: mark3labs/mcp-go#401
File: server/server.go:1082-1092
Timestamp: 2025-06-23T11:10:42.948Z
Learning: In Go MCP server, ServerTool.Tool field is only used for tool listing and indexing, not for tool execution or middleware. During handleToolCall, only the Handler field is used, so dynamic tools don't need the Tool field populated.

Applied to files:

• server/server.go

🧬 Code graph analysis (1)

server/server.go (2)

server/hooks.go (1)

• Hooks (94-121)

mcp/types.go (3)

• ReadResourceRequest (589-593)
• ResourceContents (714-716)
• Params (177-177)

🔇 Additional comments (3)

server/server.go (3)

46-48: LGTM: Resource middleware type mirrors tool middleware cleanly.
Consistent shape with ToolHandlerMiddleware; no concerns.

---

157-173: LGTM: Server state extended for resource middlewares.
Thread-safe access via middlewareMu matches existing pattern for tool middleware.

---

338-347: LGTM: Proper initialization of new maps/slices.
Zero-length slices avoid nil checks; consistent with tool middleware init.