使用Anthropic的模型上下文协议 (MCP)将任何AWS Lambda函数作为大型语言模型 (LLM)工具运行，无需更改代码。
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:2px此 MCP 服务器充当 MCP 客户端和 AWS Lambda 函数之间的桥梁，允许生成式 AI 模型以工具形式访问和运行 Lambda 函数。这非常有用，例如，无需提供公网访问权限即可访问内部应用程序和数据库等私有资源。这种方法允许模型使用其他 AWS 服务、私有网络和公共互联网。
从安全角度来看，这种方法通过允许模型调用 Lambda 函数但不直接访问其他 AWS 服务来实现职责分离。客户端只需 AWS 凭证即可调用 Lambda 函数。然后，Lambda 函数可以与其他 AWS 服务交互（使用函数角色），并访问公共或私有网络。
MCP 服务器提供两种工具：
第一个工具可以自动发现您账户中所有与前缀或允许名称列表匹配的 Lambda 函数。此工具会与模型共享这些函数的名称及其描述。
第二个工具允许通过名称传递所需的参数来调用那些 Lambda 函数。
无需更改代码。您应该更改以下配置以改善结果：
网关支持两种不同的处理 Lambda 函数的策略：
预发现模式（默认：启用）：启动时将每个 Lambda 函数注册为单独的工具。这提供了一个更直观的界面，每个函数都显示为一个独立的命名工具。
通用模式：使用两个通用工具（ list_lambda_functions和invoke_lambda_function ）与 Lambda 函数交互。
您可以通过以下方式控制此行为：
环境变量： PRE_DISCOVERY=true|false
CLI 标志： --no-pre-discovery （禁用预发现模式）
例子：
# Disable pre-discovery mode
export PRE_DISCOVERY=false
python main.py
# Or using CLI flag to disable pre-discovery
python main.py --no-pre-discovery为了让 MCP 客户端了解如何使用 Lambda 函数， Lambda 函数的描述应该明确说明该函数的功能以及使用的参数。请参阅示例函数，快速查看演示并了解更多详情。
为了帮助模型使用 AWS Lambda 提供的工具，您可以在系统提示符中添加如下内容：
Use the AWS Lambda tools to improve your answers.Related MCP server: GPT MCP App - User & Loan Info Tools
MCP2Lambda 使 LLM 能够作为工具与 AWS Lambda 函数进行交互，从而扩展其功能，使其不再局限于文本生成。这使得模型能够：
访问实时和私有数据，包括 VPC 中的数据源
使用 Lambda 函数作为沙盒环境执行自定义代码
使用 Lambda 函数互联网访问（和带宽）与外部服务和 API 进行交互
执行专门的计算或数据处理
服务器采用MCP协议，标准化了AI模型访问外部工具的方式。
默认情况下，只有名称以mcp2lambda-开头的函数才适用于模型。
Python 3.12 或更高版本
具有已配置凭证的 AWS 账户
AWS Lambda 函数（repo 中提供的示例函数）
使用Amazon Bedrock和Converse API 的应用程序
与 MCP 兼容的客户端，例如Claude Desktop
要通过Smithery自动为 Claude Desktop 安装 MCP2Lambda：
npx -y @smithery/cli install @danilop/MCP2Lambda --client claude克隆存储库：
git clone https://github.com/yourusername/mcp2lambda.git
cd mcp2lambda配置 AWS 凭证。例如，使用AWS CLI ：
aws configure此存储库包含三个示例Lambda 函数，用于演示不同的使用案例。这些函数具有基本权限，并且只能写入 CloudWatch 日志。
根据电子邮件地址检索客户 ID。此函数接受一个 email 参数并返回关联的客户 ID，演示如何构建简单的查找工具。该函数采用硬编码，用于回复user@example.com电子邮件地址。例如，您可以要求模型获取user@example.com电子邮件地址的客户 ID。
根据客户 ID 检索详细的客户信息。此函数返回客户详细信息，例如姓名、电子邮件地址和状态，展现了 Lambda 如何提供上下文相关的数据。该函数采用硬编码，用于响应上一个函数返回的客户 ID。例如，您可以要求模型“获取电子邮件user@example.com的客户状态”。这将使用这两个函数来获取结果。
在 Lambda 沙盒环境中执行任意 Python 代码。这项强大的功能允许 Claude 编写和运行 Python 代码来执行计算、数据处理或其他模型中未内置的操作。例如，您可以要求模型“计算 1 到 10、1 到 100 之间，以及 100 万以内的素数个数”。
该存储库在sample_functions目录中包含示例 Lambda 函数。
安装 AWS SAM CLI： https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html
部署示例函数：
cd sample_functions
sam build
sam deploy示例函数将以前缀mcp2lambda-进行部署。
MCP2Lambda 还可以与 Amazon Bedrock 的 Converse API 一起使用，让您可以将 MCP 协议与 Bedrock 支持的任何模型一起使用。
mcp_client_bedrock目录包含将 MCP2Lambda 连接到 Amazon Bedrock 模型的客户端实现。
有关更多信息，请参阅https://github.com/mikegc-aws/amazon-bedrock-mcp 。
Amazon Bedrock 访问和使用 Claude、Mistral、Llama 等模型的权限。
使用适当的凭证配置的 Boto3
导航到 mcp_client_bedrock 目录：
cd mcp_client_bedrock安装依赖项：
uv pip install -e .运行客户端：
python main.py客户端默认配置为使用 Anthropic 的 Claude 3.7 Sonnet，但您可以修改main.py中的model_id以使用其他 Bedrock 模型：
# Examples of supported models:
model_id = "us.anthropic.claude-3-7-sonnet-20250219-v1:0"
#model_id = "us.amazon.nova-pro-v1:0"您还可以在同一个文件中自定义系统提示来改变模型的行为方式。
在一个终端中启动 MCP2Lambda 服务器：
cd mcp2lambda
uv run main.py在另一个终端中运行 Bedrock 客户端：
cd mcp_client_bedrock
python main.py通过命令行界面与模型交互。该模型将可以访问之前部署的 Lambda 函数。
将以下内容添加到您的 Claude Desktop 配置文件中：
{
"mcpServers": {
"mcp2lambda": {
"command": "uv",
"args": [
"--directory",
"<full path to the mcp2lambda directory>",
"run",
"main.py"
]
}
}
}为了帮助模型通过 AWS Lambda 使用工具，您可以在设置配置文件中将以下句子添加到您的个人偏好设置中：
Use the AWS Lambda tools to improve your answers.本地启动 MCP 服务器：
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.
invoke_lambda_function_impllist_lambda_functions_implScored across 2 tools
The 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.
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.
