withMethodHandler resources/read

Start at the withMethodHandler API and the resources/read dispatch path, especially where handlers currently receive only decoded MCP parameters. Compare the proposed RequestContext properties with the SDK’s framework integrations, including Vapor.Request. Done means a framework-agnostic context can reach handlers without coupling the SDK to one HTTP framework, with integration coverage for supported backends.

Feature Request: Framework-Agnostic Request Context Injection for MCP Handlers

Problem

Currently, the MCP Swift SDK registers all method handlers (tools, resources, etc.) using:

@discardableResult
public func withMethodHandler<M: Method>(
    _ type: M.Type,
    handler: @escaping @Sendable (M.Parameters) async throws -> M.Result
) -> Self

This closure only receives the decoded MCP parameters (M.Parameters). There is no way to access the underlying HTTP request or any HTTP context (headers, authentication, route-local state, etc.).

Why This Is a Problem

• Many real-world handlers (especially for resources/read, but also for tools) need access to HTTP request context to:

  • Reuse existing route logic
  • Access authentication/session data
  • Read headers, cookies, or other request-scoped information
  • Share logic/state between HTTP routes and MCP handlers

• For tools, we can work around this by intercepting the HTTP request in our own route, enriching the MCP request, and passing both the MCP and HTTP request to our handler.

• For resources, this is not possible: the SDK directly invokes the handler with only the MCP parameters, and there is no extension point to inject the HTTP request.

Current Workarounds

• For resources, we are forced to use an HTTP client (e.g., URLSession) to call our own local endpoint from inside the handler, just to get the same data as the HTTP route. This is inefficient and not production-grade.
• For tools, we must maintain a custom bridge layer, which is complex and fragile.

Proposed Solution

Add support for injecting a framework-agnostic HTTP request context into MCP handler closures.

Example API

Define a protocol in the SDK, e.g.:

public protocol RequestContext {
    var headers: [String: String] { get }
    var method: String { get }
    var path: String { get }
    var query: [String: String] { get }
    var body: Data? { get }
    // ...other common properties
}

Handler registration would then look like:

@discardableResult
public func withMethodHandler<M: Method>(
    _ type: M.Type,
    handler: @escaping @Sendable (M.Parameters, RequestContext) async throws -> M.Result
) -> Self

• The SDK would provide a default implementation for each supported backend.
• Vapor integration would wrap Vapor.Request as a RequestContext.
• Other frameworks (Hummingbird, Kitura, etc.) would provide their own adapters.

Benefits

• Keeps the SDK decoupled from any specific HTTP framework.
• Enables code sharing between HTTP routes and MCP handlers.
• Allows access to authentication, headers, and other request-scoped data.
• Removes the need for inefficient HTTP self-calls and custom bridges.
• Makes the SDK more flexible and production-ready for stateless HTTP deployments.

Summary

Please add a way to inject a framework-agnostic HTTP request context into MCP handler closures. This will enable robust, efficient, and maintainable MCP server implementations in Swift, and eliminate the need for current workarounds.