Request body contention when using FastAPI middleware

[alexander-alderman-webb]

Thank you for this project! It's great to see more MCP tools.

In the Sentry Python SDK we received a bug report where the request body is consumed by FastAPI Request methods before reaching the handler. The fastapi_mcp endpoint therefore does not respond as expected because the stream is empty by the time the request is handled. See getsentry/sentry-python#4764.

Consuming the request body may be the culprit in other bugs related to using a middleware with fastapi_mcp, such as #171, although it's hard to say without more information. There is a much-discussed issue in the Starlette repository where the responses illustrate some use cases for reading the request body in the middleware (Kludex/starlette#495). In our case, we read the request body to attach to Sentry events such as exceptions in the request-handling code.

I noticed that fastapi_mcp wraps the mcp library, which works on the lower-level ASGI interface (scope, receive, send).

fastapi_mcp/fastapi_mcp/transport/http.py

Lines 80 to 86 in e5cad13

	async def handle_fastapi_request(self, request: Request) -> Response:
	"""
	Handle a FastAPI request by delegating to the session manager.
	This converts FastAPI's Request/Response to ASGI scope/receive/send
	and then converts the result back to a FastAPI Response.
	"""

Do you plan to make the library more FastAPI-friendly in the future, especially for scenarios where users register a middleware that reads request bodies. For example, by extending the pattern you have in overriding the following method?

fastapi_mcp/fastapi_mcp/transport/sse.py

Line 18 in e5cad13

async def handle_fastapi_post_message(self, request: Request) -> Response:

[alexander-alderman-webb]

If making the library more friendly to use is something you are considering, I'd be happy to investigate further which HTTP methods are affected in both transport options and propose fixes!