Stateless MCP server on Lambda

Intent

This pattern assumes an existing API behind an API gateway, whose authentication the server can share. It runs an MCP SDK's own web app unchanged on AWS Lambda, behind Lambda Web Adapter, with sessions and streaming turned off so that any instance can answer any request. It covers the compute only: what the server's tools do belongs to capabilities and safeguards for AI agents. This enables three outcomes:

1. A remote MCP server with nothing to patch or keep running, which costs nothing while idle.
2. Authentication, logging and deployment inherited from the API you already run.
3. A small codebase of your tools and your access rules, with the protocol left to the SDK.

Motivation

MCP SDKs ship a web app built for a long-running process, while Lambda hands a function one event at a time. Teams usually resolve this in one of two ways:

1. They run a container or server around the clock, paying for capacity that occasional questions rarely use.
2. They write their own translation between Lambda events and the protocol, and take on maintaining details the SDK already handles, in a specification that's still moving quickly.

This pattern avoids both. The SDK stays responsible for the protocol, and the adapter for Lambda. It also matches the protocol's direction: its 2026-07-28 revision removes sessions. Since nothing is held between requests, scaling and cold starts become ordinary Lambda concerns rather than protocol ones.

Applicability

Use this pattern when:

1. A remote MCP server should run with no servers to manage, and cost nothing when idle.
2. Its tools each answer within an API gateway's time limit.
3. The platform already has an API behind an API gateway, whose auth it can share.

Do not use this pattern when:

1. Tools run for a long time, need to stream progress, or face sustained heavy traffic. Run the same app on a container service instead, where it must verify tokens itself.

Structure

Participants

Constraints and trade-offs

1. Each request has a time limit, 29 seconds by default on a REST API, and buffered responses can't report progress as they go.
2. The server can't push anything to the client. Stateless, buffered responses rule out notifications and streaming.
3. Cold starts are felt by whoever is waiting, because a new instance has to start before it can answer.
4. Where tools must reach a private network, the function runs inside it, and every AWS service it calls needs an endpoint. Interface endpoints are charged by the hour.

Part of how I deliver

When a server should cost nothing while it waits, this is the hosting I use. It's one of many patterns I bring through contract delivery, and I choose how a server runs to suit your traffic and the platform you already have.

Related