The MCP2Lambda server allows Large Language Models (LLMs) to interact with AWS Lambda functions as tools, extending their capabilities beyond text generation without requiring code changes.
Discover Lambda Functions: View available AWS Lambda functions and their descriptions via the list_lambda_functions tool or Pre-Discovery mode.
Invoke Lambda Functions: Execute specific Lambda functions by providing the function name and JSON parameters using the invoke_lambda_function tool.
Access Private Resources: Leverage Lambda functions to interact with internal applications, databases, and VPC data.
Execute Custom Code: Run specialized calculations or data processing in a Lambda sandbox environment.
Interact with External Services: Access public internet, APIs, and other AWS services through Lambda functions.
Security and Integration: Implement segregation of duties while maintaining seamless integration with services like Amazon Bedrock's Converse API and Claude Desktop.
Allows LLMs to use AWS Lambda functions as tools, enabling models to execute code in Lambda environments, access real-time data, interact with AWS services, and perform specialized calculations without code changes. The server acts as a bridge between MCP clients and Lambda functions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP2Lambda invoke the mcp2lambda-weather-forecast function with location=Seattle"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Run any AWS Lambda function as a Large Language Model (LLM) tool without code changes using Anthropic's Model Context Protocol (MCP).
graph LR
A[Model] <--> B[MCP Client]
B <--> C["MCP2Lambda<br>(MCP Server)"]
C <--> D[Lambda Function]
D <--> E[Other AWS Services]
D <--> F[Internet]
D <--> G[VPC]
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#bbf,stroke:#333,stroke-width:2px
style C fill:#bfb,stroke:#333,stroke-width:4px
style D fill:#fbb,stroke:#333,stroke-width:2px
style E fill:#fbf,stroke:#333,stroke-width:2px
style F fill:#dff,stroke:#333,stroke-width:2px
style G fill:#ffd,stroke:#333,stroke-width:2pxThis MCP server acts as a bridge between MCP clients and AWS Lambda functions, allowing generative AI models to access and run Lambda functions as tools. This is useful, for example, to access private resources such as internal applications and databases without the need to provide public network access. This approach allows the model to use other AWS services, private networks, and the public internet.
From a security perspective, this approach implements segregation of duties by allowing the model to invoke the Lambda functions but not to access the other AWS services directly. The client only needs AWS credentials to invoke the Lambda functions. The Lambda functions can then interact with other AWS services (using the function role) and access public or private networks.
The MCP server gives access to two tools:
The first tool can autodiscover all Lambda functions in your account that match a prefix or an allowed list of names. This tool shares the names of the functions and their descriptions with the model.
The second tool allows to invoke those Lambda functions by name passing the required parameters.
No code changes are required. You should change these configurations to improve results:
The gateway supports two different strategies for handling Lambda functions:
Pre-Discovery Mode (default: enabled): Registers each Lambda function as an individual tool at startup. This provides a more intuitive interface where each function appears as its own named tool.
Generic Mode: Uses two generic tools (list_lambda_functions and invoke_lambda_function) to interact with Lambda functions.
You can control this behavior through:
Environment variable: PRE_DISCOVERY=true|false
CLI flag: --no-pre-discovery (disables pre-discovery mode)
Example:
# Disable pre-discovery mode
export PRE_DISCOVERY=false
python main.py
# Or using CLI flag to disable pre-discovery
python main.py --no-pre-discoveryTo provide the MCP client with the knowledge to use a Lambda function, the description of the Lambda function should indicate what the function does and which parameters it uses. See the sample functions for a quick demo and more details.
To help the model use the tools available via AWS Lambda, you can add something like this to your system prompt:
Use the AWS Lambda tools to improve your answers.Related MCP server: GPT MCP App - User & Loan Info Tools
MCP2Lambda enables LLMs to interact with AWS Lambda functions as tools, extending their capabilities beyond text generation. This allows models to:
Access real-time and private data, including data sources in your VPCs
Execute custom code using a Lambda function as sandbox environment
Interact with external services and APIs using Lambda functions internet access (and bandwidth)
Perform specialized calculations or data processing
The server uses the MCP protocol, which standardizes the way AI models can access external tools.
By default, only functions whose name starts with mcp2lambda- will be available to the model.
Python 3.12 or higher
AWS account with configured credentials
AWS Lambda functions (sample functions provided in the repo)
An application using Amazon Bedrock with the Converse API
An MCP-compatible client like Claude Desktop
To install MCP2Lambda for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @danilop/MCP2Lambda --client claudeClone the repository:
git clone https://github.com/yourusername/mcp2lambda.git
cd mcp2lambdaConfigure AWS credentials. For example, using the AWS CLI:
aws configureThis repository includes three sample Lambda functions that demonstrate different use cases. These functions have basic permissions and can only write to CloudWatch logs.
Retrieves a customer ID based on an email address. This function takes an email parameter and returns the associated customer ID, demonstrating how to build simple lookup tools. The function is hard coded to reply to the user@example.com email address. For example, you can ask the model to get the customer ID for the email user@example.com.
Retrieves detailed customer information based on a customer ID. This function returns customer details like name, email, and status, showing how Lambda can provide context-specific data. The function is hard coded to reply to the customer ID returned by the previous function. For example, you can ask the model to "Get the customer status for email user@example.com". This will use both functions to get to the result.
Executes arbitrary Python code within a Lambda sandbox environment. This powerful function allows Claude to write and run Python code to perform calculations, data processing, or other operations not built into the model. For example, you can ask the model to "Calculate the number of prime numbers between 1 and 10, 1 and 100, and so on up to 1M".
The repository includes sample Lambda functions in the sample_functions directory.
Install the AWS SAM CLI: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html
Deploy the sample functions:
cd sample_functions
sam build
sam deployThe sample functions will be deployed with the prefix mcp2lambda-.
MCP2Lambda can also be used with Amazon Bedrock's Converse API, allowing you to use the MCP protocol with any of the models supported by Bedrock.
The mcp_client_bedrock directory contains a client implementation that connects MCP2Lambda to Amazon Bedrock models.
See https://github.com/mikegc-aws/amazon-bedrock-mcp for more information.
Amazon Bedrock access and permissions to use models like Claude, Mistral, Llama, etc.
Boto3 configured with appropriate credentials
Navigate to the mcp_client_bedrock directory:
cd mcp_client_bedrockInstall dependencies:
uv pip install -e .Run the client:
python main.pyThe client is configured to use Anthropic's Claude 3.7 Sonnet by default, but you can modify the model_id in main.py to use other Bedrock models:
# Examples of supported models:
model_id = "us.anthropic.claude-3-7-sonnet-20250219-v1:0"
#model_id = "us.amazon.nova-pro-v1:0"You can also customize the system prompt in the same file to change how the model behaves.
Start the MCP2Lambda server in one terminal:
cd mcp2lambda
uv run main.pyRun the Bedrock client in another terminal:
cd mcp_client_bedrock
python main.pyInteract with the model through the command-line interface. The model will have access to the Lambda functions deployed earlier.
Add the following to your Claude Desktop configuration file:
{
"mcpServers": {
"mcp2lambda": {
"command": "uv",
"args": [
"--directory",
"<full path to the mcp2lambda directory>",
"run",
"main.py"
]
}
}
}To help the model use tools via AWS Lambda, in your settings profile, you can add to your personal preferences a sentence like:
Use the AWS Lambda tools to improve your answers.Start the MCP server locally:
cd mcp2lambda
uv run main.pyTool that invokes an AWS Lambda function with a JSON payload. Before using this tool, list the functions available to you.
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | Yes | ||
| parameters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool invokes a Lambda function but doesn't mention critical behavioral traits such as authentication requirements, error handling, rate limits, or what happens upon invocation (e.g., synchronous vs. asynchronous execution). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidance. Every sentence earns its place by adding clear value without redundancy, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of invoking a Lambda function, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on authentication, execution behavior, error responses, and parameter specifics, which are essential for an agent to use this tool effectively in a real-world context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It mentions 'JSON payload' which relates to the 'parameters' parameter, adding some meaning beyond the schema. However, it doesn't explain the 'function_name' parameter or provide details on payload structure, format, or constraints, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'invokes an AWS Lambda function with a JSON payload.' It specifies the verb ('invokes'), resource ('AWS Lambda function'), and payload type ('JSON payload'), which is specific and actionable. However, it doesn't explicitly differentiate from its sibling 'list_lambda_functions_impl' beyond the implied distinction between invocation and listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Before using this tool, list the functions available to you.' This indicates a prerequisite step involving the sibling tool 'list_lambda_functions_impl', offering clear context for usage. However, it lacks details on when not to use it or alternatives beyond this prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool that lists all AWS Lambda functions that you can call as tools. Use this list to understand what these functions are and what they do. This functions can help you in many different ways.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists functions but doesn't disclose behavioral traits such as whether it requires authentication, rate limits, pagination, or what the output format looks like. The description is minimal and lacks critical operational details for a tool that interacts with AWS Lambda.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, but the last two are redundant and vague ('This functions can help you in many different ways'), adding no value. It's front-loaded with the core purpose but wastes space on fluff, reducing overall efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with zero parameters, the description is incomplete. It fails to explain what the list includes (e.g., function names, ARNs, configurations) or how to interpret the results, leaving gaps in understanding the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists AWS Lambda functions, which is a clear purpose, but it's vague about what 'functions that you can call as tools' means. It doesn't distinguish from the sibling 'invoke_lambda_function_impl' tool, which would handle calling those functions. The description adds generic phrases like 'help you in many different ways' that don't clarify the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using the list to understand what functions are and what they do, implying it's for discovery, but it doesn't provide explicit guidance on when to use this tool versus the sibling 'invoke_lambda_function_impl'. There's no mention of alternatives, prerequisites, or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
invoke_lambda_function_impllist_lambda_functions_implThe two tools have clearly distinct purposes: one lists available Lambda functions, and the other invokes a specific function. There is no overlap or ambiguity between them, as they serve separate steps in a workflow.
Both tools follow a consistent verb_noun pattern with '_impl' suffix: list_lambda_functions_impl and invoke_lambda_function_impl. This naming convention is predictable and uniform across the tool set.
With only 2 tools, the server feels thin for its apparent scope of interacting with AWS Lambda functions. While it covers listing and invoking, typical Lambda operations like updating, deleting, or configuring functions are missing, making the set under-scoped.
The tool set is severely incomplete for AWS Lambda management. It only supports listing and invoking functions, lacking essential CRUD operations such as creating, updating, deleting, or monitoring functions, which limits agent capabilities in this domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Connect MCP clients to 2,000+ AI models without managing provider API keys.
Let AI agents query data and act across all your business apps via MCP.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danilop/MCP2Lambda'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
