Godot MCPセットアップ

MCPが提供する接続を理解する

Coding-Solo/godot-mcpには、Godotプロジェクトの実行、デバッグ出力の取得、シーン操作のためのツールが文書化されています。これはプロジェクトが管理するブリッジであり、モデルサービスでもGodot公式配布物でもありません。エージェントには、独自のモデルアクセスと適切なローカル権限がなお必要です。

セットアップ記録には、クライアント、MCPサーバーのリビジョン、Godot実行ファイルという3つの識別情報を保持します。一つの失敗から、他が利用できないとは判断できません。問題を調べる場所を決めるには、接続図を使います。プロバイダー認証、クライアント設定、ローカルツールプロセス、エンジンプロジェクトのどこに問題があるかを分けて考えてください。

前提条件を勝手に変えずに棚卸しする

インストール前に上流の要件を確認し、レビュー対象として特定のサーバーバージョンまたはリビジョンを選びます。対話型シェルからだけでなく、クライアントプロセスから既存のエンジンとランタイムを見つけられることを確認します。OSと対象プロジェクトディレクトリを記録してください。

依存関係を変更する前に、上流のインストール手順を確認します。ランタイム、サーバーリビジョン、インストール場所を明示し、以前の環境に戻せる方法を残します。セットアップ後は、変化するソースURLだけでなく解決済みのバージョンを記録します。これにより、後でクライアントやエンジンをアップグレードしても動作する接続を再現できます。

文書化されたローカルビルドのエントリーポイントを使う

上流のREADMEでは、build/index.jsをクライアントのエントリーポイントとし、GODOT_PATHで実行ファイルを明示的に上書きするソースビルドが説明されています。以下のJSONは、すでにビルド済みの経路をプレースホルダー付きで示したものです。各パスをレビュー済みのローカルインストールに置き換え、クライアントプロセスが読み取れることを確認します。

実際にクライアントが対応するスキーマを使ってください。一般的なmcpServersオブジェクトが、そのままCodexの設定ファイルになるわけではありません。そのクライアントの文書化された設定を通じてのみ変換し、モデルの認証情報をこのエンジンツールブロックに入れないでください。GUIクライアントとターミナルで環境が異なる場合、絶対Nodeパスが役立つことがあります。

{
  "mcpServers": {
    "godot": {
      "command": "/absolute/path/to/node",
      "args": ["/absolute/path/to/reviewed-godot-mcp/build/index.js"],
      "env": {
        "GODOT_PATH": "/absolute/path/to/godot"
      }
    }
  }
}

まず読み取り専用のツール経路を検証する

記憶した一覧に頼るのではなく、設定済みサーバーから返されたツールを調べます。READMEでは、get_godot_versionとget_project_infoが有用な検査操作として挙げられています。検出されたパラメータスキーマを確認し、承認済みのプロジェクトディレクトリだけを対象にします。

返されたエンジン情報とプロジェクト情報をセットアップ記録と比較します。構造化された結果とエラーを保持してください。観測によって意図したワークスペースが特定されるまで、シーン作成を承認しません。クライアントに接続済みバッジが表示されても、この読み取りを完了できないならゲームプレイ実験の準備はできていません。バッジだけでは、どのプロセスやプロジェクトに到達したか分かりません。

元に戻せるシーンのミニフローを一つ承認する

読み取りアクセスを検証した後、最初の書き込みには所有する使い捨てシーンを使います。元の状態を記録し、目に見える変更を一つ依頼し、保存されたシーンを検査し、実行し、出力を取得してプロジェクトを停止します。結果のファイル差分と観測結果を一緒に保持してください。

受け入れ条件は、要求した変更、保存されたリソース、目に見える実行時の動作をつなぐ連鎖です。ツールが成功を報告したのにシーンが変わらない場合は、2回目の変更を試す前にプロジェクトの対象設定と保存パスを調べます。保存後にシーンを再び開き、メモリ上の状態だけでなく永続化も確認してください。

正しい境界で失敗を診断する

プロセスの起動に失敗したら、ランタイムとエントリーポイントのパスを調べます。Godotを見つけられない場合は、クライアントの環境から実行ファイルの上書き設定を確認します。プロジェクトを検査できない場合は、project.godotを含むディレクトリを指し、プロセスが読み取れるパスか確認してください。

プロジェクトが実行できるようになったら、シーンまたはゲームプレイのエラーを再現コンテキスト付きのエンジン問題として扱います。ローカルパスの問題を直すためにプロバイダーの認証情報を変えないでください。サーバーログは慎重に取得し、共有前に機密性のあるファイルシステム情報をサニタイズします。すべてのプロジェクト操作を無差別に記録せず、詳細なデバッグ情報は一時的に保持します。

承認とネットワークの境界を狭く保つ

エンジンツールは動作中のプロジェクトを変更したり、コードを起動したりできます。適切な最小ディレクトリへのアクセスだけを許可し、動作を理解するまでは変更リクエストをレビューします。例の設定にあるように見えるからといって、広い自動承認リストをコピーしないでください。

インポートされたスクリプト、プラグイン、ツール出力は検査対象として扱い、権限を拡大する指示とはみなしません。パッケージのダウンロード、所有シーン外のファイル削除、認証情報の変更、公開には明示的な判断が必要です。最初のミニフローが成功したことは、ポリシーを見直す根拠にはなりますが、以後のすべてのツール操作を許可する理由にはなりません。

検証済みセットアップの限界を記録する

完了したセットアップ記録には、サーバーリビジョン、クライアント、エンジンバージョン、プロジェクトパス、検出されたツール、完了した読み取り、元に戻せる変更、実行時の結果を記載します。未テストの操作も明記します。普遍的な互換性保証として提示せず、ゲームの証拠とともに保管してください。

次の層は制作ループです。機能を実装し、動作を再現し、エクスポートし、対象プラットフォームでテストします。ここでの設定は上流ドキュメントに従っていますが、選択したクライアントとバージョンで検証する必要があります。範囲を限定した結果をプロジェクトとともに保持し、サーバー、エンジン、クライアントが変わるたびに同じ検査ゲートを再利用します。

よくある質問