sse-pass-http-req

[barnuri]

Motivation and Context

When working with MCP tools, particularly over Server-Sent Events (SSE), it's important to access request metadata such as headers, IP addresses, and other context. This is crucial for features like authorization, tenant resolution, request tracing, and custom routing logic. By default, SSE provides limited context handling, which poses a challenge when such metadata is needed in downstream tools.

To solve this, I extended the MCP server to inject the request context into tool invocations. This allows tools to access request headers and additional metadata even in long-lived SSE streams. The implementation also abstracts transport-specific logic, making it easy to support future transport types like WebSockets or gRPC.

How Has This Been Tested?

This change has been tested in a real MCP application with SSE transport. Scenarios tested:
Validating that tools correctly receive request headers (e.g., Authorization, X-Custom-Tenant-ID).
Injecting and accessing request query parameters within tools.
Ensuring SSE connections remain stable while context is being passed.
Fallback behavior when context is missing or malformed.
Regression tested for standard tool flows to ensure no breaking changes.

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[barnuri]

@ihrpr @jerome3o-anthropic can you review ?

[ihrpr]

• motivation and context is missing
• test evidence missing

[barnuri]

• motivation and context is missing
• test evidence missing

updated

[mcp-shadow]

1. HTTP Request Context Exposure:

   • This feature exposes HTTP transport details to tools, which breaks the transport abstraction layer that MCP is designed to maintain.
   • The MCP is designed to be transport-agnostic, and exposing HTTP-specific details leaks implementation details into the protocol.

2. Maintenance Cost & Complexity:

   • Adding this feature increases complexity by creating dependencies between the transport layer and tools.
   • It may introduce issues when other transport types are used (WebSockets, gRPC, etc.) as they would need to conform to HTTP-like interfaces.

3. Security Considerations:

   • Exposing raw HTTP request objects to tools could create security vulnerabilities if tools access sensitive headers or data.
   • No validation or sanitization of headers is implemented before passing them to tools.

4. Architectural Concerns:

   • This approach tightly couples the FastAPI implementation with the MCP protocol layer.

5. Test Coverage:

   • While the PR description mentions tests in a real application, there are no unit tests added to verify this behavior.
   • The changes to the serialization mechanism have updated tests, but the core feature has no tests.