先日 AWS Lambda MCP Server が AWS の公式からローンチされました。
そこで LangChain + LangServe を使って構築した AWS Lambda にデプロイしAPI 化していた AI エージェントを MCP ツール用に修正しました。
大変かと思っていたのですが、驚くほど小さな変更で済んだので、この記事で共有します。
LangServe アプリケーションを MCP ツールとしてデプロイする方法
前提
既存の AI エージェントは下記の技術を使って実装・デプロイしていました。
- LangChain + LangServe
- 言語は Python
- SAM (Serverless Application Model)
- サーバーレスアプリケーションのデプロイを簡略化するフレームワーク
- AWS Lambda Web Adapter
- Webアプリケーション（Express、FastAPI、ASP.NET Coreなど）をLambda上で実行するためのアダプター
- LangServe が FastAPI なので相性良し！
背景
既存の AI エージェントは LangChain をベースにした AI エージェントを構築し、LangServe で API 化していました。そしてこれを AWS Lambda にデプロイしてサーバレスで動かしていました。
また LangServe は FastAPI をベースに実装しているので、Web 画面に関しても同じアプリケーションから配信する形で社内であれば誰でも AI エージェントを使うことができる環境を整えていました。
ただその状態では LLM と会話をしつつエージェントを使いたい時は別の画面に移動して使うという手間がありました。
ですが、先日 AWS Lambda MCP Server が登場し AWS Lambda にデプロイされたアプリケーションを MCP ツールとして簡単に登録し、LLM に使ってもらうことができるようになりました。
これは対応するしかない！と思い既存の AI エージェントを MCP ツール化することに着手しました。
対応したこと
1. LangServe のルーティングを /events に変更
AWS Lambda 環境では、HTTP API 経由で受け取ったリクエストが Lambda 関数のハンドラに渡される際に、エンドポイント /events が利用される形になります。MCP ツールとして利用する際も同様に、デフォルトで /events をターゲットとしています。
そのため、LangServe のエンドポイントを /events に合わせて変更しました。
# main.py
from langserve import add_routes
from fastapi import FastAPI
from my_chain import my_langchain_app # LangChainエージェント
app = FastAPI()
add_routes(app, my_langchain_app, path="/events")これにより、Lambda 側で /events に POST されたリクエストが正しく処理されるようになります。
2. template.yaml の修正（そのままでも問題ない）
SAM で利用する template.yaml も少し調整しました。（調整なしでも使えます。）
Resources:
MCPToolMyLangChainAppFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: MCPToolMyLangChainApp # プレフィックスに MCPTool を追加
MemorySize: 256
Description: >
my app description # 説明文を追加
Tags: # タグを追加
MCPTool: "true"
MCPToolType: "MyLangChainAgent"たったこれだけです。
template.yaml の修正は別にしなくても問題ないのですが、個人的には修正した方がいいと感じたので理由を後述します。
template.yaml の修正理由
template.yaml は修正した理由としてはMCP ツールとして使いやすくするために修正をしました。
プレフィックスに MCPTool を追加、タグの設定
AWS Lambda MCP Server の公式ドキュメントにもありますが、MCP サーバーのセットアップには下記の JSON で設定します。
{
"mcpServers": {
"awslabs.lambda-mcp-server": {
"command": "uvx",
"args": ["awslabs.lambda-mcp-server@latest"],
"env": {
"AWS_PROFILE": "your-aws-profile",
"AWS_REGION": "us-east-1",
"FUNCTION_PREFIX": "your-function-prefix",
"FUNCTION_TAG_KEY": "your-tag-key",
"FUNCTION_TAG_VALUE": "your-tag-value",
}
}
}
}設定項目には、FUNCTION_PREFIX、FUNCTION_TAG_KEY、FUNCTION_TAG_VALUE があるのですが、これらの項目によってどの Lambda 関数を MCP ツールとして LLM に利用可能にするかのフィルターの役割をしています。
これらのフィルターを設定することは公式のドキュメントにもプラクティスとして明記されており、今回はそのプラクティスに沿った設定ができるように修正しました。
タグのフィルターだけでも十分なのですが、MCP サーバーの設定、AWS コンソール上での関数の検索、CloudWatch でのロググループの検索などを容易するために、関数名のプレフィックスとして MCPTool を付けました。
FUNCTION_LIST という設定プロパティもあるのですが、これを設定すると新しく MCP ツールをデプロイするたびに各個人の MCP の設定を修正する必要があり、これは手間だと感じたので使わない方針で修正を進めました。
説明文の追加
説明文の追加は MCP ツールにとってはとても重要です。
MCP ツールとは LLM が利用することができるツールのことです。
そして MCP サーバーとは MCP ツールを登録し、LLM 向けに公開するサーバーです。
LLM は MCP サーバーに登録されたツールを認識し、LLM がタスクを実行する時に必要に応じてツールを使います。
LLM は登録されたツールのメタ情報を読み取って、ツールをいつどのように使うべきかを考え必要に応じて使っていきます。
AWS Lambda MCP Server では MCP サーバーに登録されるツールのメタ情報として、Lambda 関数の関数名と説明を登録します。
つまり、LLM に正しくツールを使ってもらうには関数名と説明でツールができることを可能な限り正確かつ詳細に記載する必要があります。
そのため今までは記載していなかった説明文を今回追記しました。（※ そもそも最初からちゃんと記載しろ、という指摘は甘んじて受け入れます。。。）
注意点
関数名や関数の説明に関して自分が直面した点をいくつか紹介しておきます。
関数名は長すぎるとダメ
自分は Cursor を使って MCP サーバーの設定をしたのですが、ツール名が 60 文字を超えるとエラーになって MCP の設定ができませんでした。（これが Cursor の仕様なのか MCP サーバーの仕様なのかは調査していないので不明です…）
関数名を60文字にしたわけではないのですが、MCP 設定時にはツール名は下記のように登録されている様でした。
awslabs.lambda-mcp-server:MyLangChainAppどうやら登録されるツール名は関数名の前に awslabs.lambda-mcp-server という MCP サーバーの名前が追加されるそうです。
つまり、Lambda 関数名 ≒ MCP ツール名です。
また、関数名からは FUNCTION_PREFIX で指定した文字は消されてツール登録されるそうです。
今回は MCPTool を指定したので、登録されたツール名からは消えています。
これらの合計文字数が 60 文字を超えるとエラーになるようです。
なので LLM のために無闇に Lambda 関数名を長くしても MCP ツールとして登録する時にエラーになってしまいます。
説明文は長すぎるとダメ
LLM に正しくツールを使ってもらうためには説明文が重要だという話をしましが、残念なことに AWS の仕様として Lambda 関数に登録できる説明文には文字数制限があります。
しかもその文字数は 140 文字です。
正直、結構短いのでかなり説明文を考えるのには苦労しました。
説明文は英語の方がいい
これは絶対ではないのですが、Lambda の説明文は英語の方がいいと感じでいます。
英語で説明文を書く方が、LLM がよりツールを正しく認識し、使ってくれる感覚があります。
※ あくまで個人的な感覚です。
おそらく LLM の学習は基本は英語でされているから、英語の方がより正確に読み取ってくれるのだと勝手に思っています。
まとめ
大変だろうなと思って、AWS Lambda MCP Server の対応を始めたのですが、やってみるとかなり簡単で、拍子抜けしました。
また実装よりも設定周りで細かい仕様の部分で地味にハマったのは想定外でした。
皆様の参考になると幸いです。
