使用したエディタと実行先

remote の MCP を使う作業は VSCode Remote SSH、編集は拡張と LSP を切った Zed に分けました。エディタは M1 Mac、推論と MCP は EPYC + Blackwell の compute server に置いています。

検証した環境では、Zed は MCP command を Mac で起動し、VSCode Remote SSH は compute 側で起動しました。実行先と PATH の違いを確認した記録です。

配置の計画と変更

当初の計画

当初は compute に VSCode Server / Zed Remote Server を置き、Mac を thin client にする計画でした。

  • VSCode Server または Zed Remote Server を compute 側で動かす
  • MCP サーバーも compute 側で起動し、ローカルの runtime をそのまま使う
  • Mac はターミナルとブラウザの操作端末にする

現実の構成

Mac の資源も使うため、エディタは Mac に置きました。

  • Zed: remote 編集用。拡張（ext）と LSP は切って、純粋なエディタとして使う
  • VSCode Remote SSH: MCP が必要なときはこちらを使う
  • compute server は推論サーバーと MCP サーバーの実行環境として使う

MCP は compute の uvx、python、コンテナ runtime を使う要件です。

必要な条件です。

  • remote 側の PATH とバイナリをそのまま参照できること
  • セッション終了時にプロセスがきれいに消えること
  • 常駐プロセスを増やしすぎないこと
  • 必要なら podman run --rm で都度起動できること

commandが動くホスト

同じ command 指定でも、起動するホストによって PATH と使える runtime が変わります。

vscode-serverのセットアップ.md では1接続構成とし、runtime を self-contained にする方針でした。MCP も remote subprocess として扱います。

Zedのlocal起動

Zed は .zed/settings.json を remote に置いても、remote の uvx / python を使いませんでした。command は Mac 側で解決されます。

remote に入れた runtime を参照できず、PATH の段階で要件と合いませんでした。

今回の Zed MCP は stdio の local 起動でした。mcp-remote proxy も検討しましたが、使用した構成の SSE 非対応で、remote 接続をそのまま扱えませんでした。

Zed で遭遇した具体的な問題

確認した問題です。

  • remote 側に入っている uvx や serena が参照されない
  • ローカルの uvx 経由で serena を起動しても、compute server 側の PATH を使えない
  • port forward を張っても、MCP の起動主体がローカルのままなので効果が薄い
  • remote 側に新しい LISTEN プロセスはなく、MCP の起動を確認できませんでした

設定場所を変えるだけでは、起動するホストは変わりませんでした。

VSCodeのremote起動

VSCode Remote SSH は拡張ホストが remote で動きます。mcp.servers の command と args が compute の PATH と環境を使いました。

Python / uvx は compute の環境を使い、接続を閉じると MCP subprocess も終了しました。

podman run --rm で必要時にコンテナを起動し、終了時に削除する方式にしました。

実際の挙動（ss -ltnp で確認）

ss -ltnp で compute の users:(("python",pid=xxxx)) の LISTEN を確認しました。VSCode 接続を閉じると消え、remote の subprocess として動くことを確認できました。

Zed の試行では、同じ remote LISTEN は現れませんでした。この違いから client を切り替えました。

最終設計の方向性

MCP は /opt/containers/runtime/mcps/run.sh から起動する方針です。内部で podman run --rm を呼び、依存、volume 範囲、後始末を管理します。

VSCode の MCP command がこの wrapper を呼び、remote subprocess として動かします。セッション終了時の停止と、--rm による削除を組み合わせます。

利用頻度が高い MCP は、SSE + quadlet の常駐も今後の候補です。現在は subprocess を使っています。

用途による使い分け

今回の構成では、compute の runtime を使う要件に VSCode Remote SSH が合いました。Zed の remote 編集だけでは MCP の実行先は変わりませんでした。

MCP は VSCode Remote SSH、編集は Zed（ext/LSP 切り） を使います。LLM導入の開発環境では、podman run --rm と /opt/containers/runtime/mcps/run.sh で実行環境を分ける構成です。

エディタを Mac、MCP を compute に置き、両方の資源を使います。

今後の作業

次は run.sh の引数、環境変数、volume 規約と、VSCode の mcp.servers 設定例を固める予定です。

常駐化は起動回数、初期化コスト、共有 cache が必要かを基準に検討します。