WSLで慣れてるとハマる?CursorのMCP設定でつまづいた話
普段、Windowsで開発していると、ついWSL上で作業するのが当たり前になってしまいますよね。僕もその一人で、今回もWSL上でMCPサーバを立ち上げて「動いた動いた」と安心していました。
ところが、CursorエディタでMCPの設定をしたところ、なぜかエラーが発生。MCPサーバ自体はWSLで普通に動いてるのに、Cursor側からうまく接続できなかったんです。
いろいろ試してみた結果、MCPサーバをWindows側で立ち上げ直したら、すんなり動作。どうやら、CursorがMCPを起動・接続する際には、ホスト側の環境(つまりWindows側)に依存する部分があるようです。
WSLでの作業に慣れている人ほど気づきにくいポイントかもしれません。同じようなことでハマった人の参考になれば幸いです!
前提
- MCPサーバはModel Context Protocolのサーバソースを使う
- サーバはnpxを使う
- ローカルでPostgreSQLが立ち上がっている
- Cursorバージョンは0.49
導入手順
MCPサーバ設定
Windows側のコマンドプロンプトで、
git clone git@github.com:modelcontextprotocol/servers.git
npm install
npm run build
ちなみに、ここではビルドまでしておくだけでよく(サーバを立ち上げっぱなしにするのではなく)Cursorが都度立ち上げて使う仕組みらしい
Cursor設定
Cursor上でCursor Settings→MCPから設定しても良いし、プロジェクトフォルダ配下に.cursor/mcp.jsonを作成しても良い
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/postgres"
]
}
}
}
動作確認
エラーの場合はOutput→Cursor MCPにログが出る
Agentプロンプトでテーブルのことについて聞けば、自動的にMCPを使って、PostgreSQLに対して実際にクエリを発行してテーブルの中身を見たり、列の構成を確認してソースコード開発に反映したりしてくれる
Tavily
Linuxでは一時的にインライン環境変数を指定してMCPを起動しますが、Windowsでは以下のようにして動きました
{
"mcpServers": {
"TAV2": {
"command": "cmd",
"args": [
"/C",
"set TAVILY_API_KEY=tvly-xxxxxxxxxxxxxxx && npx -y tavily-mcp@0.1.3"
],
"type": "stdio"
}
}
}