こんにちは! yu_Matsuです
最近 MCP(Model Context Protocol) が話題になっていますね! GitHubやSlack、Google Driveなど、さまざまなサービスがMCPサーバーを提供しており、生成AIアプリケーションの開発により柔軟性が増してきました。
今回の記事では、このMCPを振り返るとともに、自分で実装する場合はどんな感じなのかについて見ていきます。また、実装したMCPサーバーを広く利用してもらうための方法の一つとして、AWS ECS(Elastic Container Service)上でサーバーをたててみたいと思います。
本記事の内容に関するサンプルコードをGitHubで公開していますので参考にしていただければと思います。また、記事タイトルにある通り、おまけとしてTerraformでのコード化のサンプルと解説もありますので、合わせてご覧ください。
MCPは、アプリケーションがLLM(大規模言語モデル)にコンテキスト情報を提供する方法を標準化するプロトコルであり、Claudeシリーズを開発したAnthropic社が提唱しました。(ここでいう「コンテキスト」とは、LLMが会話や情報を適切に理解し処理するために必要な背景情報のことです。)
現在の生成AIアプリケーションのメインストリームであるAIエージェントは、ユーザーの入力に対して最適解を得るために、思考と行動を繰り返します。この行動のフェーズで必要な情報をコンテキストとして取得するのですが、この処理は「ツール」として実装されることが多いです。
従来の生成AIアプリ開発では、このツールを、同じような処理を行うものであっても(例えばよく利用されるGmailやSlackなどを扱うツール)、その都度実装/連携する必要があったり、開発に利用されるフレームワークやプログラミング言語によって実装方法が異なるため、他者に提供しづらい、といった問題がありました。
しかし、MCPによりこのような問題が解決され、さまざまな生成AIアプリケーションが、コンテキスト情報取得のためのツールを共用できるようになりました。また、単なるプロトコルの提唱だけでなく、簡単にアプリケーションに組み込めるようにSDK(ソフトウェア開発キット) まで用意されているため、現在急速に普及しています。
MCPの基本構造としては、下図のような クライアント・サーバー・アークテクチャ に基づいていまして、以下の概念が存在します。
- MCPホスト:Claude DesktopやGitHubCopliot、Clineなど、後述するMCPクライアントを内包した生成AIアプリケーション
- MCPクライアント:MCPに則ってサーバーと接続、LLMの指示をサーバーに渡し、その処置結果を受け取る
- MCPサーバー:MCPに則って、特定の機能を提供するプログラム
(https://modelcontextprotocol.io/introduction から引用)
MCPに関しては、以下の資料が非常に分かりやすくまとまっていますので、一度ご覧いただければと思います。
簡単なMCPサーバーの実装
MCP公式ドキュメントのQuickstartを実施して、簡単なMCPサーバーを構築してみましょう。
Quickstartをほぼ愚直に実施するだけですので、もう試されたことがある方は流し読みしていただいて大丈夫です!
また、GitHubのサンプルコードを実行しながら読み進められる場合は、mcp_serverディレクトリに移動して以下を実行してください
- 下記の手順を参考にuvのインストールと仮想環境のアクティベート
-
uv sync
を実行
Pythonのパッケージ管理ツールであるuvを利用して、MCPサーバー用のプロジェクトを作成します。
# プロジェクトの作成
uv init mcp_server
cd mcp_server
# 仮想環境のアクティベート
uv venv
source .venv/bin/activate
# パッケージのインストール
uv add fastmcp httpx # 「FastMCP」の v2 をインストールしている
# MCPサーバーを実装するファイルの作成
touch weather.py
Quickstartと異なる点は、MCPサーバー作成に利用する「FastMCP」に関して、v2 をインストールしているところです。FastMCPはMCPサーバーやMCPクライアントを実装しやすくなるSDKであり、v2はMCP公式のPython用SDKであるv1を拡張したものになります。詳しくは以下のドキュメントをご覧ください。
それでは、MCPサーバーを実際に実装していきます。(といっても、Quickstart通りですが…)
weather.py
from typing import Any
import httpx
from fastmcp import FastMCP
# Initialize FastMCP server
mcp = FastMCP("weather")
# Constants
NWS_API_BASE = "https://api.weather.gov"
USER_AGENT = "weather-app/1.0"
まずは必要なライブラリをインポートし、FastMCPクラスを初期化しています。このクラスにより、MCPサーバーのツール実装が容易になります。また、天気情報を取得する外部APIのURLの定数の定義もここでしています。
次に、MCPサーバーで提供するツール群の実装になります。機能としては以下の2つになります
- get_alerts: 州名から、その州で発生している気象警報の情報を調べて返す
- get_forecast: 緯度と経度から、そのエリアの気象予報を調べて返す
weather.py
async def make_nws_request(url: str) -> dict[str, Any] | None:
"""Make a request to the NWS API with proper error handling."""
headers = {
"User-Agent": USER_AGENT,
"Accept": "application/geo+json"
}
async with httpx.AsyncClient() as client:
try:
response = await client.get(url, headers=headers, timeout=30.0)
response.raise_for_status()
return response.json()
except Exception:
return None
def format_alert(feature: dict) -> str:
"""Format an alert feature into a readable string."""
props = feature["properties"]
return f"""
Event: {props.get('event', 'Unknown')}
Area: {props.get('areaDesc', 'Unknown')}
Severity: {props.get('severity', 'Unknown')}
Description: {props.get('description', 'No description available')}
Instructions: {props.get('instruction', 'No specific instructions provided')}
"""
まずは、ヘルパー関数の実装になります。
make_nws_request は、APIのURLを受け取ってAPIを実行、そのレスポンスから必要な情報のみ取り出して返します。get_forecast、get_alerts共通で利用されます
format_alertは、気象警報情報を整形して返します。get_alertsでのみ利用されます
weather.py
@mcp.tool()
async def get_alerts(state: str) -> str:
"""Get weather alerts for a US state.
Args:
state: Two-letter US state code (e.g. CA, NY)
"""
url = f"{NWS_API_BASE}/alerts/active/area/{state}"
data = await make_nws_request(url)
if not data or "features" not in data:
return "Unable to fetch alerts or no alerts found."
if not data["features"]:
return "No active alerts for this state."
alerts = [format_alert(feature) for feature in data["features"]]
return "\n---\n".join(alerts)
@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
"""Get weather forecast for a location.
Args:
latitude: Latitude of the location
longitude: Longitude of the location
"""
# First get the forecast grid endpoint
points_url = f"{NWS_API_BASE}/points/{latitude},{longitude}"
points_data = await make_nws_request(points_url)
if not points_data:
return "Unable to fetch forecast data for this location."
# Get the forecast URL from the points response
forecast_url = points_data["properties"]["forecast"]
forecast_data = await make_nws_request(forecast_url)
if not forecast_data:
return "Unable to fetch detailed forecast."
# Format the periods into a readable forecast
periods = forecast_data["properties"]["periods"]
forecasts = []
for period in periods[:5]: # Only show next 5 periods
forecast = f"""
{period['name']}:
Temperature: {period['temperature']}°{period['temperatureUnit']}
Wind: {period['windSpeed']} {period['windDirection']}
Forecast: {period['detailedForecast']}
"""
forecasts.append(forecast)
return "\n---\n".join(forecasts)
次に、ツール群本体の実装です。
といっても、開発者が意識するのは関数の内容のみであり、普通に関数を実装すれば良いです。
- get_alerts: 外部APIの気象警報情報を取得するためのURLを作成し、先ほどのmake_nws_requestに渡して実行することで、結果を取得します。そして、format_alertで整形し、返しています
- get_forecast: 外部APIの気象予報を取得するためのURLを作成し、make_nws_requestに渡して実行します。レスポンスの中から直近5日分の情報を抽出して返しています
それぞれの関数に、コードの最初の方で生成したFastMCPインスタンスのデコレーターである、@mcp.tool() をつけることで、関数をツール化することができます。Pythonに慣れていれば、かなり直感的であることが分かるかと思います。
最後に、サーバーを起動する処理を記述することで、実装完了です!!
weather.py
if __name__ == "__main__":
# Initialize and run the server
mcp.run(transport='stdio')
mcp.runの引数として、transport=”stdio” を指定していますが、こちらの詳細に関しては後述します。
Claude Desktopでの動作確認
それでは、動作確認をしてみましょう。
まずは、Quickstartに合わせてClaude Desktopで確認してみます。VSCodeがお手元にある場合は、以下のコマンドを実行して設定ファイルを開きます。
Macの場合になります
code ~/Library/Application\ Support/Claude/claude_desktop_config.json
開いたclaude_desktop_config.jsonに、以下の内容を記述します。もしすでに他のMCPサーバーの設定がある場合は、weather以下の内容を追加してください。これで設定完了です。
claude_desktop_config.json
{
"mcpServers": {
"weather": {
"command": "uv(Mac/Linuxの場合はuvの絶対パス)",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/mcp_server",
"run",
"weather.py"
]
}
}
}
では、Claude Desktopを開いてみましょう。
ユーザー入力欄の「+」ボタン隣のツールボタンを押下してみると、MCPサーバーが追加されていることが分かります。
ちゃんと get_alerts、get_forecast ともにツールが有効になっています!
Quickstartの入力例である、「What’s the weather in Sacramento?」を入力してみます。
Tips: 今回作成したMCPサーバーをClaude Desktopで動作確認をする際は、ツールの「ウェブ検索」をオフにすることをお勧めします。
ツールの外部連携使用許可に関するメッセージが表示されますが、とりあえず「常に許可する」にします。
エージェントが思考を始めました。MCPサーバーで提供している get_forecast をちゃんと利用してくれていることが分かります。
最終的な回答が返ってきました。サクラメントの気象予報を答えてくれていることが分かります!
ついでに、気象警報についてもQuickstartの入力例「What are the active weather alerts in Texas?」を入力してみます。
こちらも問題なく get_alerts を使ってくれています。
取得した情報を、format_alert で整形して返してくれていることが分かります。
GitHub Copilotでの動作確認
次はGitHub Copilotでも動作確認してみます。
VSCodeを開き、下記の記事を参考に、setting.jsonを開いてください。
setting.jsonに以下の内容を追記してください。
setting.json
{
"mcp": {
"servers": {
"weather": {
"command": "uv(Mac/Linuxの場合はuvの絶対パス)",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/mcp_server(絶対パス)",
"run",
"weather.py"
]
}
}
}
}
すると、「weather」の上の方に「起動」と出てきますので、起動します。
「実行中」になれば、起動成功です
Tips: ここまでの流れを見てもらえれば分かると思いますが、Claude Desktop、Copliot等のMPCホストからMCPサーバーに接続する際は、ローカルであっても手元で先にuv run weather.py
などでサーバーを起動しておく必要がありません。
しかし、後述するMCP InspectorやMCPクライアントから接続する場合は先にサーバーを起動しておく必要があることに注意しましょう。
Copilotのチャット画面を開くと、ユーザー入力部分にツールのマークが出ていますので、押下して確認してみましょう。MCPサーバーが追加されていることが分かります。
それでは、Claude Desktop と同様に、「What’s the weather in Sacramento?」と入力してみます。
Claude Desktopと同様に、MCPサーバーの get_forecast を利用して気象予報を取得して返していることが分かります。
MCP Inspector での動作確認
先ほどまで、Claude Desktop や GitHub Copilot などのMCPホストを利用して動作確認を行っていましたが、いきなりMCPホストに繋ぎ込みに行く前に、MCP Inspectorというツールを利用することで、簡単にローカルで動作確認できます。
Tips: 実際にMCPサーバーを開発する際は、まずはMCP Inspectorで動作確認してからMCPホスト、MCPクライアントに繋ぎ込みに行く方が良いでしょう。
まず、MCPサーバーの仮想環境に入っているコマンドプロンプト/ターミナルで以下のコマンドを実行し、MCPサーバーを起動します。
次に、別のコマンドプロンプト/ターミナルを開き、以下のコマンドを実行してInspectorを起動します。
npx -y @modelcontextprotocol/inspector
すると、InspectorのURLが実行ログに表示されますので、ブラウザでアクセスします。
左メニューでMCPサーバーの接続設定を行い、「Connect」を押下してサーバーに接続します。
- Transport Type: STDIO
- Command: uv (mac/linuxの場合でもフルパスでなくてOK)
- Arguments: –directory /ABSOLUTE/PATH/TO/PARENT/FOLDER/mcp_server run weather.py (それぞれスペースで間を空ける)
接続に成功したら、以下のような画面になります。
「Tools」タブを開き、「List Tools」を実行して、get_alerts とget_forecast が表示されれば一先ず接続確認は完了ということになります。
ローカルでサーバーを立てての動作確認は完了しましたが、ECSに載せるにはDockerイメージを作成する必要があります。ということで、次はDockerイメージの作成し、そこからサーバーをたててみましょう。
まずは、mcp_serverディレクトリの下に以下のDockerfileを作成します。
# Pythonのバージョンはお手元のものに合わせる
FROM python:3.11
# Set working directory
WORKDIR /app
# Install system dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
gcc \
python3-dev \
&& rm -rf /var/lib/apt/lists/*
# Copy requirements first for better caching
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Copy the application code
COPY . .
# Set environment variables
ENV PYTHONUNBUFFERED=1
# Command to run the application
CMD ["python", "weather.py"]
イメージ作成時にインストールが必要なパッケージ一覧を期待した requirements.txt は以下のような内容で、同じくmcp_serverディレクトリ下に作成します。
requirements.txt
httpx>=0.28.1
fastmcp>=2.3.1
次に、Dockerイメージをビルドします。先にDocker Desktopを起動しておいてください。
以下のコマンドでをmcp_severディレクトリで実行してください。
docker build -t mcp-server .
問題なくビルドが完了したら、準備完了です!
MCP Inspectorでの動作確認
それでは、先に MCP Inspectorで動作確認してみましょう。ローカルでの起動確認時と同様に、MCP Inspectorを起動します。また、以下のコマンドで、Dockerイメージからサーバーを起動しておきます。
docker run -i --rm mcp-server
そして、MCPサーバーの接続設定として以下を入力して、サーバーに接続します。
- Transport Type: STDIO
- Command: docker
- Arguments: run -i –rm mcp-server
接続に成功し、Toolsからツール一覧を取得できれば確認完了です。
確認が終わりましたら、起動しているサーバーを docker stop で停止しておきましょう。
Claude Desktop での動作確認
Claude Desktopでも確認しておきます。
ローカルの場合と同様に、設定ファイルを開いて以下のように編集します。
claude_desktop_config.json
"weather": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"mcp-server"
]
}
設定の変更が完了したので、Claude Desktopを再起動してみます。ツールが利用できる状態であるので、MCPサーバーに接続できていることが分かります。
ではいつもの質問をしてみましょう。
ツールをちゃんと使ってくれていること、意図した回答が返ってきていることが分かります。
これで、DockerからのMPCサーバー起動の確認は完了です!
※ Copilotでの動作確認は省略します。設定ファイルに記載する内容はClaude Desktopと同様になりますので、ご自身で試してみてください。
いよいよECSでのリモートMCPサーバーの構築に移ります!
まずは、現在のMCPサーバーのコードをリモート対応するために少し修正します。
weather.py
if __name__ == "__main__":
# Initialize and run the server
- mcp.run(transport="stdio")
+ mcp.run(transport="streamable-http", host="0.0.0.0", port=8000, log_level="debug")
MCPサーバー実行処理を記述している部分の transport の指定を streamable-http に変更します。また、コンテナ外からのアクセスを受け付けるためにhostを0.0.0.0にバインド、ポートを8000に指定しています。
GitHubのサンプルコードを実行しながら読み進めていただいている場合は、mcp_server/weather.py の L103 mcp.run(transport="stdio")
をコメントアウトし、L104 mcp.run(transport="streamable-http", host="0.0.0.0", port=8000, log_level="debug")
をコメントインしてください
MCPサーバーのトランスポートについて
ここで、トランスポートについて見ておきましょう。
トランスポートは、MCPサーバーとMCPホスト/クライアントで情報をやり取りするための方法で、Stdio(標準入出力)とStreamable HTTPの2種類あります。今まで、ローカルやDockerでMCPサーバーを起動する場合はトランスポートにstdioを、今回リモートMCPサーバーをたてる上でstreamable-httpを指定しました。
Stdioは「標準入出力」の名の通り、MCPサーバーをローカルホストで起動し、MCPホスト/クライアントも同じローカル環境から接続しにいくような場合に利用します。標準入力(stdin)と標準出力(stdout)を通じてデータがやり取りされます。
Streamable HTTPは、HTTPベースでMCPサーバーとホスト/クライアント間でデータのやり取りをする方式になります。リモートMCPサーバーのように、MCPホスト/クライアントがインターネット越しでMCPサーバーに接続する必要がる場合などに利用されます。
従来は HTTP + SSE(Server-Side Events) 方式が利用されていましたが、それを代替、補完する方式として普及しつつあります。現状のMCP界隈ではまだHTTP + SSE方式が主流ですが、今後Streamable HTTPに置き換わっていくとのことです。
AWSのリソースの作成
ECS自体がAWSのサービスの一つですが、その他にもいろいろ必要ですので、作成していきましょう。
まずは、ECSを配置するネットワーク周りです。記事スペースの都合上詳しい作成手順等は省略させていただきますが、以下のリソースを作成してください。(後述しますが、GitHubのTerraformのコードも参考にしていただければと思います。)
- VPC
- パブリックサブネット(2AZ分)
- インターネットゲートウェイ
- ルートテーブル
- S3へのVPCエンドポイント
- セキュリティグループ
- インバウンド、アウトバウンドともにすべてのトラフィックを許可
本来はECSをプライベートサブネットに配置するべきですし、セキュリティグループもしっかり絞る必要がありますが、今回はお試しのため上記のようにしています。実際に広く提供するようなリモートMCPサーバーをたてる場合は、セキュリティ観点を踏まえた上でアーキテクチャを検討しましょう。
次に、Dockerイメージを管理するECR(Elastic Container Registory)のリソース作成です。
ECRのコンソールに移動し、「リポジトリを作成」を押下します。
リポジトリ作成画面に遷移するので、リポジトリ名にDockerイメージと同じ名前を入力します(今回は「mcp-server」)。また、イメージタグのミュータビリティは「Mutable」にしておきます。
イメージリポジトリの作成が完了したら、Dockerイメージをpushしていきます。「プッシュコマンドを表示」を押下すると、実行すべきコマンド一覧が表示されます。
今回は、Dockerイメージのビルドはもう出来ているので、実行するコマンドは 1、3 ~ 4になります。
一通り完了すると、リポジトリにイメージがpushされます。
次に、ECSでMCPサーバーをたてる工程です。
ECSのコンソール左メニューから「タスク定義」を開き、「新しいタスク定義の作成」を押下します。
タスク定義作成画面に遷移するので、タスク定義ファミリー名を指定します。
インフラストラクチャの要件を指定します。
起動タイプは「AWS Fargate」、オペレーティングシステム/アーキテクチャは、Dockerイメージをビルドした環境に合わせて選択します。(筆者の環境だと「Linux/ARM64」)
タスクロールとタスク実行ロールですが、今回は同じIAMロールを選択します。このロールは、ポリシーとしてマネージドのAmazonECSTaskExecutionRolePolicyのみを持つロールとなっており、タスク定義と並行して作成しておいてください。
(もし、AWSの他のサービスにアクセスするようなMCPサーバーをたてる場合は、タスク実行ロールは適切な権限を持つものを作成してください。)
最後に、コンテナの設定です。
コンテナイメージとして、先ほどpushしたイメージのURIを入力します。
また、ポートマッピングは下画像のように設定してください。
あとの設定はそのままで、タスク定義の作成は完了です。
次に、ECSクラスター/サービスの作成です。
コンソール左メニューの「クラスター」を開いて、「クラスターの作成」を押下します。
クラスターの作成画面に遷移するので、クラスター名とインフラストラクチャを下画像のように指定し、作成します。
クラスターの作成が完了したら、サービスの作成に移ります。クラスター画面の「サービス」タブの「作成」を押下します。
サービスの作成画面に遷移するので、下画像を参考に設定をしてください。ネットワーキングの項目は、作成したVPCやセキュリティグループを選択、パブリックIPは有効にします。
設定が完了したら、サービスを作成します。数分かかることがありますので、気長に待ちましょう。
サービスの作成が完了したら、タスクが一件起動開始しているかと思います。「タスク」タブから確認できます。(下画像は「タスク(2)」となっていますが、気にしないでください)
タスク名を押下すると、タスクの詳細画面が開きます。「前回のステータス」が「実行中」になっていれば正常起動完了です。「パブリックIP」はこの後MCPサーバーへの接続に利用しますので、控えておいてください。
「ログ」タブを開くと、サーバーログを確認することができます。このログはCloudWatch Logsに出されているものになりますので、ログ監視等も可能です。
MCP Inspectorでの動作確認
さて、無事にリモートMCPサーバーが起動しましたので、例の如くまずはMCP Inspectorでの動作確認を実施します。今までと同様にローカルでMCP Inspectorを立ち上げてブラウザで開きます。
左メニューで以下の接続設定をして、「Connect」を押下します。
- Transport Type: Streamable HTTP
- URL: http://ECSタスクのパブリックIP:8000/mcp/
問題なく接続できました!
「Tools」タブでツール一覧を取得してみます。
問題なく取得できていそうです!
ちなみにこの時点でECSタスクのログを確認すると、サーバーに ListToolsRequest が行われていることが分かります。
Claude Desktop / GitHub Copilotでの動作確認
次に、Claude Desktopでの動作確認をしてみましょう。
基本的には今までと同様に設定ファイルを変更すれば良いのですが、一点注意が必要で、Claude DesktopはリモートMCPサーバーを直接サポートしていません。(当記事執筆時点)ですので、ローカルプロキシを間に噛ませてあげる必要があります。
今回はmcp-remoteというローカルプロキシを使いたいと思いますので、以下のコマンドでインストールしてください。
npm install -g mcp-remote
インストールが完了しましたら、設定ファイルを開いて以下のように編集します。
claude_desktop_config.json
"weather": {
"command": "mcp-remote(Mac/Linuxの場合はuvの絶対パス)",
"args": [
"http://ECSタスクのパブリックIP:8000/mcp/",
"--allow-http"
]
}
では、Claude Desktopを再起動してみましょう。
以下のように、ツールアイコンを開いてツールが有効化されていれば、リモートMCPサーバーへの接続成功です!
試しにお馴染みの質問をしてみましょう。
今回は日本語で「サクラメントの天気を教えて!」と質問してみました。
ちゃんと動いていそうです!
タスクのログを確認しても、外部APIが呼び出されていることが確認できます。
無事にECSでリモートMCPサーバーをたてることができました!🎉
GitHub Copilotでも動作確認しておきます。CopilotはリモートMCPサーバーをサポートしているため、接続設定は以下のようにかなりシンプルになります。
setting.json
"weather": {
"type": "http",
"url": "http://ECSタスクのパブリックIP:8000/mcp/"
}
Claude Desktopと同じ質問をしてみましたが、ツールを利用して回答してくれていそうです!
LangChainで実装したMCPクライアントで動作確認
今までは、Claude DesktopやGitHub CopilotのようなMCPホストで動作確認をしていましたが、自前のアプリケーションに組み込んだエージェントから利用することを想定して、LangChainで実装したMCPクライアント(厳密にはMCPホストに近い気がしますが)でも動作確認してみたいと思います。LangChainは、LLMを活用したアプリケーション開発を効率化するためのフレームワークです。
mcp_serverディレクトリと同階層に、uv init
で新しくmcp_clientというディレクトリを作成し、mcp_serverディレクトリの時と同じように仮想環境を作成してください。
※ 今までとは別のコマンドプロンプト/ターミナルを開いて作業してください。
GitHubのサンプルコードを実行しながら読み進めていただいている場合は、ここら辺の作業は必要ありませんが、別コマンドプロンプト/ターミナルでmcp_clientディレクトリを開き、仮想環境のアクティベートとuv sync
を実行してください
今回はLangChain関連のパッケージが必要になるので、以下のコマンドで追加してください
uv add langchain-mcp-adapters langchain-aws langgraph boto3 streamlit
mcp_clientディレクトリ下にmain.pyを作成し、以下のようなコードを記述します。
main.py
import os
import asyncio
from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain_aws import ChatBedrockConverse
from langgraph.prebuilt import create_react_agent
from dotenv import load_dotenv
load_dotenv()
async def call_agent(user_input):
# Select the model
model = ChatBedrockConverse(
model="us.anthropic.claude-3-7-sonnet-20250219-v1:0"
)
async with MultiServerMCPClient(
{
"weather": {
"url": os.environ['MCP_SERVER_ENDPOINT_HTTP'],
"transport": "streamable_http",
}
}
) as client:
# Create the agent with tools
agent = create_react_agent(model, client.get_tools())
# Simple invocation without callbacks
response = await agent.ainvoke({"messages": user_input})
return response
if __name__ == "__main__":
user_input = input("Enter your input: ")
response = asyncio.run(call_agent(user_input))
for message in response["messages"]:
print(message.content)
LangChain(厳密にはLangGraphですが)でエージェントを実装する一つの手段として、create_react_agent
があります。モデルのインスタンスと、エージェントが利用できるツール群を渡してあげることでエージェントを作成してくれます。
今回は、エージェントに渡すツールをMCPサーバーから取得できるように、MultiServerMCPClientを利用しています。コンフィグとしてMCPホストで設定するものと似たような記述をすることで、MCPサーバーに接続することができます。(マルチなので複数サーバーを設定可能)
MCPサーバーのURLは環境変数に外出ししているため、以下のような内容の.envファイルを作成してください。
.env
MCP_SERVER_ENDPOINT_HTTP=http://ECSタスクのパブリックIP:8000/mcp/
また、以下も併せて実行しておいてください。
- バージニア北部リージョンのAmazon Bedrockのコンソールで、Anthropic系のモデルを有効化
- お手元のAWS CLIのプロファイルに関してバージニア北部用のものを作成して切り替えるか、コマンドプロンプト/ターミナルで環境変数
AWS_REGION
の値をus-east-1に変更
それではuv run main.py
で実行してみます。
同じく日本語で「サクラメントの天気を教えて」と入力してみたところ、緯度経度に変換してget_forecastを実行してくれています。
最終的な回答内容もバッチリでした!
ちなみに、記事スペースの都合上コードの掲載はしませんが、Streamlitで簡単なWebアプリケーション(main_gui.py)も作成していますので、気になる方はサンプルコードをご覧ください。
以下のコマンドで起動できます。
streamlit run main_gui.py
起動後、以下のような画面がブラウザで開くので、サイドバーでリモートMCPサーバーのURLを入力、使用したいモデルを選択してください。
あとは、質問を入力し、実行すればエージェントから回答が返ってくるようになっています。(雑なプログラムなので動作不良等あるかもしれませんが、ご了承ください)
このように、比較的簡単に、かつ直感的にMCPクライアントを作成し、システムに組み込むことが出来るということもお分かりいただけるかと思います!
今回はLangChainを利用しましたが、AWS公式からも Inline Agents SDK が提供されており、MCPサーバーに対応しています。Inline Agents SDKを利用した記事もいろいろ出ていますので、調べてみてください。
とりあえず、ECSでリモートMCPサーバーをたてることは出来ましたが、今後のアクションとしてはどのようなことが考えられるでしょうか。
セキュリティ面の強化
前セクションで再三お伝えしている通り、今回は作成したものはあくまでハンズオンレベルになりますので、セキュリティ面が考慮されていません。もし実運用を考えるのであれば、最低限以下のような対応が必要になるかと思います。
- ECSをプライベートサブネット内に配置する
- MCPサーバーにhttpsで安全に通信できるように、ECSの前段にALB(Application Load Balancer) を設ける
- セキュリティグループを適切に設定することが併せて必要
- MCPサーバーにOAuthなどの認証機構を導入し、ツールを保護する(こちらを参照)
CloudflareにMCPサーバーをデプロイする
自分でリモートMCPサーバーを環境から構築するとなると上記のようなこと配慮する必要がありますが、実はCloudflareにMCPサーバーをデプロイすることで簡単に実現できます。また、環境の維持コストやスケーラビリティなども担保されるので、Cloudflareを利用可能であれば非常に有益な手段であると言えます。
今回はMCPとは何だったのかを軽く振り返りつつ、簡易なMCPサーバーのたて方や、それをリモートサーバー化する方法例についての記事でした。
MCPは現在の生成AIシーンでは非常に重要な概念となっており、生成AIアプリケーションの進化をさらに一段階進めたのではないかと考えています。しかし、一見難しそうに見えて考え方はシンプルであり、SDKを利用することで非常に簡単にMCPサーバーをたてられることがお分かりいただけたかと思います。
提供されているMCPサーバーを利用するだけでなく、実際に自分で構築してみることで見えてくることも多々あるかと思いますので、しっかりMCPを使いこなしていきましょう!
本記事はこれで以上になります。ご高覧いただきありがとうございました!
もし本格的にリモートMCPサーバーを運用していくとなった際に、今回手動で作成したインフラリソース周りをコード化して管理しておく必要が出てくることもあるかと思います。
ですので、このセクションではTerraformでのコード管理(Infrastructure as Code = IaC)について簡単に触れておきます。
Terraformは、HashiCorp社で開発されているIaCツールであり、AWSやGCPなどのクラウドサービス上のインフラリソースをコードで定義し、コードに基づいたインフラ環境を自動構築することができる優れものです。
当記事のサンプルコードのterraformディレクトリ下で、今回手動で作成したリソース群のコードを作成していますので、興味がある方はご覧ください。本記事ではデプロイの仕方だけ掲載します。
まずは、Terraformのコマンドを実行するためにインストールしてください。バージョン管理を簡単にするために、tfenvでのインストールをお勧めします。
次に、terraformディレクトリに移動、以下のコマンドを実行してterraformの初期化を行います。
AWS CLIのプロファイルや環境変数AWS_REGIONをバージニア北部リージョンに切り替えている方は、東京リージョン(ap-northeast-1)に戻しておいてください。
初期化が完了すると、以下のようなメッセージが出ます。
次に、以下のコマンドを実行し、コードからどのようなリソースが作成され得るか、を確認します。(dry-runのようなものになります)
成功すると、以下のように作成される予定のリソース一覧が表示されます。今回は新規作成のみなので緑色の「+」ばかりですが、もしTerraformで管理している既存のリソースから変更がある場合は「〜」で表現されたり、削除されるリソースや設定があれば赤色の「-」で表現されます。
Terraformでどのリソースを管理しているかは、terraform plan
の実行後に自動的に作成される、terraform.tfstateをいうファイルに記載されます。次回以降のplanで変更箇所がある場合は、tfstateファイルと見比べて差分が検出される、という仕組みです。
作成予定の内容に問題がなければ、以下のコマンドでapply(デプロイ)していきます。
実行すると、一度planが実行され、本当にapplyしても良いかの確認が入りますので、「yes」と入力します。すると、applyが開始されます。
以下のようなメッセージが出たら、apply完了です!
これで、コードからリソースが作成されたわけですが、実はまだ終わりではありません。
まず、ECRのリポジトリは作成されたものの、イメージがpushされていませんので、リポジトリのpushコマンド一覧を参考に、イメージをpushしてください。(イメージをビルドする際、イメージ名はECRリポジトリ名を合わせた方が良いかもしれません)
あとは、ECSのサービス自体は作成されているのですが、タスクが起動していない状態です。これは、TerraformでECSサービスの定義をする際に、必要とするタスク数(desire_count)を0で設定したからです。(apply完了後にイメージがpushされていないので、自動でタスクを起動しても失敗する)
ですので、ECSサービスの設定を、「新しいデプロイの強制」にチェックを入れ、「必要なタスク」を 「1」 で更新してください。すると、タスクが起動します。
手動で作成した際と同様に、タスクの実行に成功したら完了です!
Terraformでのデプロイから動作確認まで完了しましたら、もし必要がなければ terraform ディレクトリ下でterraform destroy
を実行すると、コード管理しているリソースが全て削除されます。実運用では禁じ手のコマンドですが、ハンズオン後の片付け作業などでは便利です。
Views: 0