The interesting move here is not that Lambda becomes a tool — it is that the credential you hand the client only permits invocation. Private databases and internal applications stay reachable without ever granting the model network access to them, and every call already runs inside your own logging and IAM. The work shifts from writing integrations to writing good function descriptions.
A bridge between an MCP client and AWS Lambda. The client holds credentials that can only invoke functions; each function then reaches whatever it needs — other AWS services, a VPC, the public internet — under its own execution role. That split is the design: the model can call the function but cannot touch what the function touches.
- Autodiscovery of the Lambda functions in your account that match a prefix or an allowed list, passing their names and descriptions to the model
- Invocation of those functions by name with parameters
- Pre-Discovery Mode, on by default, which registers each function as its own named tool
- Generic Mode as the alternative — two tools, `list_lambda_functions` and `invoke_lambda_function` — selected with `PRE_DISCOVERY=false` or the `--no-pre-discovery` flag
- A default name filter: only functions starting with `mcp2lambda-` are offered to the model
- Three sample functions in the repo, deployable with `sam build` and `sam deploy`, including one that runs arbitrary Python inside the Lambda sandbox
Python 3.12 or higher, an AWS account with credentials configured (`aws configure`), and the functions you want to expose. The package is `mcp2lambda`, started with `uv run main.py`. One thing carries more weight than any setting: the model reads each function's own Lambda description to decide when to call it, so that description has to say what the function does and which parameters it takes.