Run Model Context Protocol (MCP) servers with AWS Lambda

This project enables you to run Model Context Protocol stdio-based servers in AWS Lambda functions.

Currently, most implementations of MCP servers and clients are entirely local on a single machine. A desktop application such as an IDE or Claude Desktop initiates MCP servers locally as child processes and communicates with each of those servers over a long-running stdio stream.

flowchart LR
    subgraph "Your Laptop"
        Host["Desktop Applicationwith MCP Clients"]
        S1["MCP Server A(child process)"]
        S2["MCP Server B(child process)"]
        Host |"MCP Protocol(over stdio stream)"| S1
        Host |"MCP Protocol(over stdio stream)"| S2
    end

This library helps you to wrap existing stdio MCP servers into Lambda functions. You can invoke these function-based MCP servers from your application using the MCP protocol over short-lived HTTPS connections. Your application can then be a desktop-based app, a distributed system running in the cloud, or any other architecture.

flowchart LR
    subgraph "Distributed System"
        App["Your Applicationwith MCP Clients"]
        S3["MCP Server A(Lambda function)"]
        S4["MCP Server B(Lambda function)"]
        App |"MCP Protocol(over HTTPS connection)"| S3
        App |"MCP Protocol(over HTTPS connection)"| S4
    end

Using this library, the Lambda function will manage the lifecycle of your stdio MCP server. Each Lambda function invocation will:

1. Start the stdio MCP server as a child process
2. Initialize the MCP server
3. Forward the incoming request to the local server
4. Return the server’s response to the function caller
5. Shut down the MCP server child process

This library supports connecting to Lambda-based MCP servers in four ways:

1. The MCP Streamable HTTP transport, using Amazon API Gateway. Typically authenticated using OAuth.
2. The MCP Streamable HTTP transport, using Amazon Bedrock AgentCore Gateway. Authenticated using OAuth.
3. A custom Streamable HTTP transport with support for SigV4, using a Lambda function URL. Authenticated with AWS IAM.
4. A custom Lambda invocation transport, using the Lambda Invoke API directly. Authenticated with AWS IAM.

Determine your server parameters

Many stdio-based MCP servers’s documentation encourages using tools that download and run the server on-demand. For example, uvx my-mcp-server or npx my-mcp-server. These tools are often not pre-packaged in the Lambda environment, and it can be inefficient to re-download the server on every Lambda invocation.

Instead, the examples in this repository show how to package the MCP server along with the Lambda function code, then start it with python or node (or npx --offline) directly.

You will need to determine the right parameters depending on your MCP server’s package. This can often be a trial and error process locally, since MCP server packaging varies.

Passing credentials and other secrets to the MCP server

This library does not provide out-of-the-box mechanisms for managing any secrets needed by the wrapped MCP server. For example, the GitHub MCP server and the Brave search MCP server require API keys to make requests to third-party APIs. You may configure these API keys as encrypted environment variables in the Lambda function’s configuration or retrieve them from Secrets Manager in the Lambda function code (examples below). However, note that anyone with access to invoke the Lambda function will then have access to use your API key to call the third-party APIs by invoking the function. We recommend limiting access to the Lambda function using least-privilege IAM policies. If you use an identity-based authentication mechanism such as OAuth, you could also store and retrieve API keys per user but there are no implementation examples in this repository.

If your MCP server needs to call AWS APIs (such as the MCP servers for AWS), you can pass the Lambda function’s AWS credentials to the wrapped MCP server via environment variables. The wrapped MCP server’s child process does not automatically inherit the Lambda execution role’s credentials. Again, note that anyone with access to invoke the Lambda function will then have access to use the function’s AWS credentials to call AWS APIs by invoking the function. We recommend limiting access to the Lambda function using least-privilege IAM policies.

Use API Gateway

flowchart LR
    App["MCP Client"]
    T1["MCP Server(Lambda function)"]
    T2["API Gateway"]
    T3["OAuth Server(Cognito or similar)"]
    App -->|"MCP StreamableHTTP Transport"| T2
    T2 -->|"Invoke"| T1
    T2 -->|"Authorize"| T3

This solution is compatible with most MCP clients that support the streamable HTTP transport. MCP servers deployed with this architecture can typically be used with off-the-shelf MCP-compatible applications such as Cursor, Cline, Claude Desktop, etc.

You can choose your desired OAuth server provider for this solution. The examples in this repository use Amazon Cognito, or you can use third-party providers such as Okta or Auth0 with API Gateway custom authorization.

Use Bedrock AgentCore Gateway

flowchart LR
    App["MCP Client"]
    T1["MCP Server(Lambda function)"]
    T2["Bedrock AgentCore Gateway"]
    T3["OAuth Server(Cognito or similar)"]
    App -->|"MCP StreamableHTTP Transport"| T2
    T2 -->|"Invoke"| T1
    T2 -->|"Authorize"| T3

This solution is compatible with most MCP clients that support the streamable HTTP transport. MCP servers deployed with this architecture can typically be used with off-the-shelf MCP-compatible applications such as Cursor, Cline, Claude Desktop, etc.

You can choose your desired OAuth server provider with Bedrock AgentCore Gateway, such as Amazon Cognito, Okta, or Auth0.

Using Bedrock AgentCore Gateway in front of your stdio-based MCP server requires that you retrieve the MCP server’s tool schema, and provide it in the AgentCore Gateway Lambda target configuration. AgentCore Gateway can then advertise the schema to HTTP clients and validate request inputs and outputs.

To retrieve and save your stdio-based MCP server’s tool schema to a file, run:

npx @modelcontextprotocol/inspector --cli --method tools/list  > tool-schema.json

# For example:
npx @modelcontextprotocol/inspector --cli --method tools/list uvx mcp-server-time > tool-schema.json

Some MCP servers generate tool schemas that AgentCore Gateway rejects with strict validation, such as "items": {}, "default": null, or anyOf with {"type": "null"}. You may need to clean up the schema before using it:

python3 scripts/clean-tool-schema.py tool-schema.json

Use a Lambda function URL

flowchart LR
    App["MCP Client"]
    T1["MCP Server(Lambda function)"]
    T2["Lambda function URL"]
    App -->|"Custom Streamable HTTPTransport with AWS Auth"| T2
    T2 -->|"Invoke"| T1

This solution uses AWS IAM for authentication, and relies on granting Lambda InvokeFunctionUrl permission to your IAM users and roles to enable access to the MCP server. Clients must use an extension to the MCP Streamable HTTP transport that signs requests with AWS SigV4. Off-the-shelf MCP-compatible applications are unlikely to have support for this custom transport, so this solution is more appropriate for service-to-service communication rather than for end users.

Use the Lambda Invoke API

flowchart LR
    App["MCP Client"]
    T1["MCP Server(Lambda function)"]
    App -->|"Custom MCP Transport(Lambda Invoke API)"| T1

Like the Lambda function URL approach, this solution uses AWS IAM for authentication. It relies on granting Lambda InvokeFunction permission to your IAM users and roles to enable access to the MCP server. Clients must use a custom MCP transport that directly calls the Lambda Invoke API. Off-the-shelf MCP-compatible applications are unlikely to have support for this custom transport, so this solution is more appropriate for service-to-service communication rather than for end users.

Related projects

• To write custom MCP servers in Lambda functions, see the MCP Lambda Handler project.
• To invoke existing Lambda functions as tools through a stdio MCP server, see the AWS Lambda Tool MCP Server project.

Considerations

• This library currently supports MCP servers and clients written in Python and Typescript. Other languages such as Kotlin are not supported.
• This library only adapts stdio MCP servers for Lambda, not servers written for other protocols such as SSE.
• This library does not maintain any MCP server state or sessions across Lambda function invocations. Only stateless MCP servers are a good fit for using this library. For example, MCP servers that invoke stateless tools like the time MCP server or make stateless web requests like the fetch MCP server. Stateful MCP servers are not a good fit, because they will lose their state on every request. For example, MCP servers that manage data on disk or in memory such as the sqlite MCP server, the filesystem MCP server, and the git MCP server.

Deploy and run the examples

See the development guide for instructions to deploy and run the examples in this repository.

Security

See CONTRIBUTING for more information.

License

This project is licensed under the Apache-2.0 License.