feat: Provide an option to increase request payload size in server implementation

[siwachabhi]

Description

Is your feature request related to a problem? Please describe.
When building a server which can accept larger than 4MB payload size, current implementation has a fixed limit to reject it.

Describe the solution you'd like
Make this a configurable parameter, so servers can configure

Describe alternatives you've considered
Workaround is to use something like this: https://stackoverflow.com/questions/12496089/how-can-i-override-a-constant-in-an-imported-python-module, which can backward incompatible.

Other options is to provide a separate path for larger file I/O, but that seems redundant.

Additional context

python-sdk/src/mcp/server/streamable_http.py

Lines 337 to 344 in 5441767

	body = await request.body()
	if len(body) > MAXIMUM_MESSAGE_SIZE:
	response = self._create_error_response(
	"Payload Too Large: Message exceeds maximum size",
	HTTPStatus.REQUEST_ENTITY_TOO_LARGE,
	)
	await response(scope, receive, send)
	return

References

No response

[pantanurag555]

It makes sense to make this configurable by servers. Different servers will have different input size requirements. While the 4MB HTTP request limit is quite common among web server implementations, this depends on the server owner. Additionally HTTP itself does not impose any such limit.

I will draft a PR to make this configurable for servers in python-sdk.

[Kludex]

Why does MCP defines this?

[Kludex]

Why does MCP defines this?

My point was that the HTTP server can define this. Also, the way we set this setting is after reading the body - which doesn't make sense, because you want to avoid putting that in memory.

[pantanurag555]

My point was that the HTTP server can define this.

Not sure how this would work for FastMCP where the SDK sets up the Starlette app under the server to receive requests. The Starlette app doesn't seem to provide a capability to restrict body size based on this discussion: Kludex/starlette#890. I see that you are a Starlette maintainer, so I am open to any suggestions that you might have.

Also, the way we set this setting is after reading the body - which doesn't make sense, because you want to avoid putting that in memory.

That makes sense. I am going to modify it such that the body is streamed in chunks until the size goes above the configured max size (at which point MCP errors out).

[Kludex]

My suggestion is to let the server handle it (uvicorn, or your reverse proxy).

The discussion about Starlette supporting this has the same conceptual issue.

[pantanurag555]

Currently, FastMCP sets up a Uvicorn server under the hood. Uvicorn only allows us to set the max message size for messages sent using the websockets protocol. There are no settings for http max message size that can be set afaik.

Based on some online reading, the best ways to enforce message sizes in such a case are via the the application or reverse proxies. It is definitely possible to setup MCP servers that work without reverse proxies (for development and for local testing being primary use cases). This would make the max size setting transferable to production use cases without having to do additional setting on the infra side. Given this is already something that is enforced as part of MCP, I think we can extend it for the ease of use of server owners.

However, I also realize that in production scenarios there will be reverse proxies and in those cases the server owner might also need to set a max message size to ensure they do not run out of memory when handling large requests. If you believe it doesn't make sense to have the setting in MCP due to redundancy, I can go ahead and change my PR to remove the setting altogether. Let me know what you think.

[pantanurag555]

@Kludex Let me know your final thoughts when you get some time.

[pantanurag555]

Issue resolved: #1105