AnthropicのModel Context Protocol (MCP)を使用して、コードを変更することなく、任意のAWS Lambda関数を Large Language Model (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サービスに直接アクセスできないようにすることで、職務の分離を実現します。クライアントはLambda関数を呼び出すためにAWS認証情報のみを必要とします。Lambda関数は、関数ロールを使用して他のAWSサービスとやり取りし、パブリックネットワークまたはプライベートネットワークにアクセスできるようになります。
MCP サーバーは、次の 2 つのツールへのアクセスを提供します。
最初のツールは、アカウント内のプレフィックスまたは許可された名前のリストに一致するすべてのLambda関数を自動検出します。このツールは、関数の名前と説明をモデルと共有します。
2 番目のツールを使用すると、必要なパラメータを渡して名前で Lambda 関数を呼び出すことができます。
コードの変更は不要です。結果を改善するには、以下の設定を変更する必要があります。
ゲートウェイは、Lambda 関数を処理するための 2 つの異なる戦略をサポートしています。
事前検出モード（デフォルト：有効）：起動時に各Lambda関数を個別のツールとして登録します。これにより、各関数がそれぞれの名前付きツールとして表示される、より直感的なインターフェースが提供されます。
汎用モード: 2 つの汎用ツール ( 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-discoveryMCPクライアントに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 と対話する
特殊な計算やデータ処理を実行する
サーバーは、AI モデルが外部ツールにアクセスする方法を標準化する MCP プロトコルを使用します。
デフォルトでは、名前がmcp2lambda-で始まる関数のみがモデルで使用できます。
Python 3.12以上
認証情報が設定された AWS アカウント
AWS Lambda 関数 (リポジトリで提供されているサンプル関数)
Converse APIを備えたAmazon Bedrockを使用したアプリケーション
Claude DesktopのようなMCP互換クライアント
Smithery経由で Claude Desktop 用の MCP2Lambda を自動的にインストールするには:
npx -y @smithery/cli install @danilop/MCP2Lambda --client claudeリポジトリをクローンします。
git clone https://github.com/yourusername/mcp2lambda.git
cd mcp2lambdaAWS 認証情報を設定します。例えば、 AWS CLIを使用します。
aws configureこのリポジトリには、異なるユースケースを示す3つのサンプルLambda関数が含まれています。これらの関数は基本的な権限を持ち、CloudWatchログへの書き込みのみが可能です。
メールアドレスに基づいて顧客IDを取得します。この関数は、メールアドレスをパラメータとして受け取り、関連付けられた顧客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 とも併用できるため、Bedrock でサポートされているどのモデルでも MCP プロトコルを使用できます。
mcp_client_bedrockディレクトリには、MCP2Lambda を Amazon Bedrock モデルに接続するクライアント実装が含まれています。
詳細については、 https://github.com/mikegc-aws/amazon-bedrock-mcpを参照してください。
Claude、Mistral、Llama などのモデルを使用するための Amazon Bedrock アクセスと権限。
適切な資格情報で構成された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"同じファイル内のシステム プロンプトをカスタマイズして、モデルの動作を変更することもできます。
1 つのターミナルで 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.
