MCP servers don't always need containers, persistent processes, or a full web framework.
For many tools, a regular Python AWS Lambda is enough: But some operations are different.
A tool may spend 30 seconds searching, analyzing, or coordinating work and need to report progress while it runs.
For those workloads we need real Streamable HTTP: We wanted both models in Python without requiring applications to adopt different MCP programming models.
That led to two open-source projects: modmex-lambda — the Python MCP runtime and programming model. serverless-python-mcp — the Serverless Framework deployment integration.
Together they let a Python application start with a lightweight buffered MCP server and opt into real Lambda response streaming when the workload actually needs it.
Start with a regular Python Lambda The simplest deployment doesn't require Lambda Web Adapter or response streaming.
Install : Create an MCP server: Then expose capabilities as regular Python functions.
Tools Resources Prompts Mount the MCP server on the normal API Gateway resolver: The resulting architecture is deliberately boring: For short-lived tools, resources, and prompts, that's usually exactly what we want.
No FastAPI.
No Flask.
No ASGI server.
No response-streaming infrastructure.
Just Python and Lambda.
MCP is another interface to the application layer One of the design goals was not to create a separate application architecture for MCP.
Tools can use the same dependency injection mechanisms as regular Lambda endpoints: That means REST and MCP can remain thin interfaces over the same application services: The same idea applies to middleware.
Authorization, tenant resolution, logging, auditing, tracing, and policies don't need to be implemented inside every tool: MCP becomes another transport into the application rather than another application architecture.
Why buffered MCP is useful It's easy to associate MCP with streaming, but many MCP operations don't benefit from it.
Consider: If a tool finishes in 300 milliseconds or two seconds, a normal Lambda response is simpler.
For this reason, streaming isn't a requirement in .
You can run MCP through a regular managed Python Lambda and API Gateway HTTP API v2.
That gives us the first deployment model: Then, when a workload actually needs incremental communication, we can move to the second model.
When buffered responses stop being enough Consider a tool that performs several expensive steps: Maybe the complete operation takes 30 or 40 seconds.
With a buffered response, the MCP client sees nothing until the function finishes.
Instead, we want the tool to report progress: Those progress reports are translated into MCP messages and sent over the same Streamable HTTP response before the final JSON-RPC result.
Now we need real response streaming.
Real MCP streaming from Python Lambda For streaming, provides .
The application remains Python: The infrastructure changes underneath it: Lambda Web Adapter connects the HTTP response produced by the Python application with Lambda response streaming.
Now an MCP tool can emit progress while it is still running: The Lambda invocation hasn't completed when those progress messages reach the MCP client.
That's real incremental MCP streaming.
Deployment is the second half of the problem Getting streaming to work inside Python is only part of the job.
A streaming Lambda deployment also needs the right infrastructure: We didn't want every Python MCP service to reproduce that configuration manually.
That's why we built .
Install it: and register it like any other Serverless Framework plugin: MCP servers are declared under .
Lightweight deployment with HTTP API v2 For a normal buffered MCP server: The application uses: The plugin creates a normal Lambda behind API Gateway HTTP API v2.
No Lambda Web Adapter is added.
No streaming launcher is added.
This remains the lightweight deployment path.
Streamable deployment with REST API When the same class of application needs rea